ninemin.lilulab.ai

“Agent stopped due to iteration limit or time limit.” — LangChain’s string is your output

{'input': '...', 'output': 'Agent stopped due to iteration limit or time limit.'}

This is the most widely pasted of the strings on this site and the most widely misunderstood, because it is not an error message. It is a constant that LangChain’s AgentExecutor puts in the output key where your answer was going to go. Nothing raised, nothing logged at error level, the chain returned normally. If you print result["output"], you print that sentence; if you write it to a database, you have stored that sentence as an answer. And the steps the agent did finish are sitting right there in the same call, which is the part worth staying for.

Where this string comes from

The loop stops on a condition that deliberately covers both limits:

def _should_continue(self, iterations: int, time_elapsed: float) -> bool: if self.max_iterations is not None and iterations >= self.max_iterations: return False return self.max_execution_time is None or time_elapsed < self.max_execution_time

and when it does, the executor asks the agent for a stopped response and returns it through the same path a successful answer takes:

output = self._action_agent.return_stopped_response( self.early_stopping_method, intermediate_steps, **inputs, ) return self._return(output, intermediate_steps, run_manager=run_manager)

The string itself is in the agent, not the executor:

if early_stopping_method == "force": # `force` just returns a constant string return AgentFinish( {"output": "Agent stopped due to iteration limit or time limit."}, "", ) msg = f"Got unsupported early_stopping_method `{early_stopping_method}`" raise ValueError(msg)

Quoted verbatim from libs/langchain/langchain_classic/agents/agent.py at commit 5a9b1ec2. Note the path: on master the AgentExecutor lives in langchain_classic, not in langchain.agents. If you went looking for this code at the path in an older answer, that is why you did not find it.

The file contains two different stopped strings. Which one you got identifies your agent.

There are three implementations of return_stopped_response in that one file, and they do not agree:

• BaseSingleActionAgent returns "Agent stopped due to iteration limit or time limit." for "force" — and raises ValueError for anything else, including "generate".
• BaseMultiActionAgent returns a different sentence for the same method: "Agent stopped due to max iterations." — shorter, and notably without the “or time limit”.
• Agent, the older LLM-and-prompt class, returns the first sentence for "force" and supports "generate", which does one final forward pass over the thoughts so far instead of returning a constant.

So in Python the sentence you got is a fact about which base class your agent subclasses, not about which limit stopped it. Both of the modern runnable agents inherit from one of the two base classes above — RunnableAgent from BaseSingleActionAgent and RunnableMultiActionAgent from BaseMultiActionAgent — which has a consequence worth knowing before you go looking for the documented escape hatch: early_stopping_method="generate" raises ValueError on a single-action runnable agent. The field’s own docstring offers “Either 'force' or 'generate'”; the implementation you are probably running accepts only the first.

If you are in TypeScript, you almost certainly got the other one

The JavaScript package splits the two strings differently, and the difference is a piece of dead code. In libs/langchain-classic/src/agents/agent.ts, returnStoppedResponse under "force" returns:

return { returnValues: { output: "Agent stopped due to max iterations." }, log: "", };

while the other sentence lives in a method on the executor itself:

_returnStoppedResponse(earlyStoppingMethod: StoppingMethod) { if (earlyStoppingMethod === "force") { return { returnValues: { output: "Agent stopped due to iteration limit or time limit.", }, log: "", } as AgentFinish; }

Nothing calls that method. The two places the TypeScript executor actually stops — _stop() in the iterator and the fall-out at the end of _call — both call this.agent.returnStoppedResponse(...), which is the first block. So in TypeScript the sentence at the top of this page is reachable only by calling a method the library never calls itself, and the output you will have seen is Agent stopped due to max iterations.

Both quotations from agents/agent.ts and agents/executor.ts at commit b261746b. The “no caller” claim is scoped to exactly that: a search of those two files at that commit found the declaration of _returnStoppedResponse and no call to it. We have not searched the rest of the repository or any package that imports it. The TypeScript maxIterations default is also 15, and its _shouldContinue tests the iteration count only — there is no time term in it at all, which makes the “or time limit” wording doubly inapt on that side.

If you are reading this because a tool built on the TypeScript package gave you a capped run — n8n’s older AI Agent node versions are the common case — then the string to check your output against is the shorter one.

Confirm it in ten seconds

The sentence names two limits and tells you nothing about which one fired. You can resolve that from your own configuration without another run, because of the defaults:

max_iterations: int | None = 15 max_execution_time: float | None = None early_stopping_method: str = "force"

• If you never set max_execution_time, it was the iteration limit. The default is None, and the condition above cannot stop a run on time when it is None. The “or time limit” half of the sentence is unreachable in a default configuration. That is the whole ten-second check for most readers.
• If you did set both, time the call. A run that stops noticeably short of max_execution_time hit the iteration ceiling; a run that stops at it did not.
• If you want the count itself, pass return_intermediate_steps=True and read len(result["intermediate_steps"]). Fifteen steps and that sentence is an iteration ceiling with the default still in place.

And the check that belongs in your code rather than in a terminal: compare result["output"] against the two constants above and treat a match as a failure. They are constants in the library, which is the one thing that makes this reliable — nothing else about a capped run differs from a successful one.

Why raising max_iterations moves the wall

Fifteen is the default. An iteration is one pass of the agent loop: one model call, then the tool call it asked for. Raising it to 50 buys 35 more passes, and if your task genuinely needed 19, that is the correct fix and the page ends for you here.

What does not change is the ending. The terminal act of a capped AgentExecutor is to substitute a constant for your answer. It does that at 15 and it does it at 1,500; the larger number only buys more model calls before the substitution. And because the substitution is silent, the cost of getting it wrong grows with the cap: an agent looping without a reachable stopping condition under a cap of 15 wastes fifteen calls, and the same agent under a cap of 200 wastes two hundred and returns the identical string. There is also a second ceiling most readers have left at None: max_iterations set to None is documented in the source as something that “could lead to an infinite loop”, so removing the limit is not a fix either.

The restructure: the finished steps are already in the return value

This framework gives you something the others on this site do not, and it costs one keyword argument.

Set return_intermediate_steps=True. Look again at the call site above: the stopped path calls self._return(output, intermediate_steps, ...), with the same intermediate_steps list the successful path passes. Inside _return, those steps are attached to the result when the flag is on. So on a capped run you get back every (action, observation) pair the agent completed, in order, alongside the substituted sentence. The finished work is not lost at all — by default it is simply never handed to you. Turn the flag on, treat the two constant strings as failure, and process the steps.

Then make each step durable rather than merely returned. Steps that only exist in the return value are lost if the process dies rather than the loop ending. The general move is the one every page on this site arrives at: have each tool write its own result where the next attempt can find it, so a second run is a continuation instead of a replay.

And make one iteration do more. A step that handles one item and a step that handles forty cost the same single model call. Runs that reach fifteen iterations are usually not hard, they are iterative — a model walking a list by hand because every tool it was given takes one element. Hand it a tool that takes the list and the iteration count stops tracking the item count.

What is behind this site

The short version: Agent stopped due to iteration limit or time limit. is not an error, it is the value of result["output"] — a constant substituted for your answer when the loop runs out of iterations. With the defaults, max_execution_time is None, so it was the iteration limit at 15. A multi-action agent gets a different constant, Agent stopped due to max iterations., and early_stopping_method="generate" raises on a single-action runnable agent. Set return_intermediate_steps=True and the finished steps come back with the substituted string; check the output against both constants, and raise the cap only when you can say how many iterations the task needs.