What are the three canonical stopping conditions for an agent loop? For each, briefly describe how it is detected. Then explain why cost cap is harder to implement correctly than the other two.
The three stopping conditions are final-answer signal, step budget, and cost cap. Cost cap is hardest because next-step cost is unknown until after the call and compounds as context grows.
Imagine you give a helper a task and a few rules for stopping. First, they stop when they say they are finished. Second, they stop after a fixed number of tries, no matter what. Third, they stop once they have spent a set amount of money. The first two rules are easy to check. "Did they say done?" is a yes or no question. "Have they tried ten times?" is just counting. But the money rule is sneaky. You only learn the price of a try after it happens, not before. And each new try costs more than the last, because the helper carries a growing pile of notes along every time. So it is easy to blow past your budget on the very step that pushes you over, since you could not see the bill until the work was already done.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
An agent is an LLM in a loop: it observes the running state, reasons about the next move, calls a tool, reads the observation, and repeats. The single most dangerous property of that loop is that it has no natural end. A plain function call returns once. A loop driven by a probabilistic model can run until something external tells it to stop. That something is the set of stopping conditions, and getting them right is what separates a demo from a system you can put a budget behind.
The right mental model is layered termination. You combine a soft, intended exit with hard backstops underneath it. The intended exit is goal-based: the agent finishes when the task is actually done. The backstops are resource-based: they fire on steps or spend regardless of whether the task is done, so a misbehaving agent cannot run forever or drain a budget. Goal verification sits on top of the soft exit, because the model claiming completion and the goal actually being satisfied are two different things.
There are three canonical stopping conditions: the final-answer signal, the step budget, and the cost cap. They are not interchangeable. The final-answer signal is the intended, graceful exit. The step budget and the cost cap are hard backstops that exist precisely because the model cannot be trusted to halt itself. This answer covers how each is detected, why relying on the model alone is unsafe, why the cost cap is the hardest of the three to implement correctly, and what a loop should do when a backstop forces a stop.
The three conditions and how each is detected
The final-answer signal is the model declaring victory. The model emits a designated phrase, a sentinel token, or a structured tool call such as a finish action, and the runtime detects it by pattern matching the output or by parsing a typed schema. This is the only one of the three that is driven by the model's judgement.
The step budget is a hard ceiling on iterations. The runtime keeps an integer counter, increments it once per loop turn, and exits when the counter reaches its limit, typically somewhere from ten to forty turns. Detection is perfectly deterministic: the runtime owns the counter, so there is no ambiguity and no dependence on anything the model says.
The cost cap is a ceiling on spend. The runtime accumulates the token counts from every model call, and ideally every billable tool call, multiplies by the per-token price, and exits when the running total crosses a dollar or token ceiling. Detection requires a running sum that the runtime must maintain accurately across heterogeneous cost sources.
In production these three are layered, not chosen between. The final-answer signal handles the happy path. The step and cost backstops fire when the happy path fails. A robust loop wires all three and exits on whichever triggers first.
A fourth condition often joins them in practice: no-progress detection. The runtime hashes the tool name and normalised arguments each turn and compares against recent turns. If the agent reissues the same action two or three times in a row, that is the signature of a stuck loop, and the runtime either injects a corrective message or terminates. It is not one of the three canonical stops, but it catches the failure mode where the agent burns steps and tokens without moving toward the goal, which neither a final-answer match nor a raw counter would notice in time.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- LangGraph exposes a recursion_limit that caps loop iterations and raises a GraphRecursionError, the framework-level step budget acting as a hard backstop.
- The Anthropic SDK returns a usage field with input and output token counts on every call, letting a loop reconcile real cost after each step rather than guessing.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you enforce a cost cap that almost never overshoots, even on a step that returns a huge tool output?
Estimate the worst-case cost of the next call before issuing it, using current context length plus the model's max output tokens at the per-token price. Refuse to start any call whose projected cost would breach the remaining budget, and cap tool outputs at ingestion so a single blob cannot spike a step.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Trusting the model's final-answer signal as the only stop. A confused agent declares done prematurely or never, so hard backstops on steps and cost must run independently of what the model claims.
60 second bullets to scan on the way to the call.
Name the three canonical stopping conditions and how each is detected.
Explain why the model alone cannot be trusted to decide it is done.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.