ModelRefs / Stopping Condition — AI Glossary
Stopping Condition — AI Glossary
A criterion determining when an agent loop should terminate, either by task completion, error threshold, or resource limit.
Overview
Stopping conditions: task completed (LLM emits a final-answer tool call or stops generating tool calls), max iterations reached, error rate threshold exceeded, cost budget exhausted, or human interrupt signal received. Well-defined stopping conditions are essential for production agents to avoid infinite loops and runaway API costs.
Reference details
| Topic | agents |
|---|---|
| Last reviewed | 2026-06-24 |
Related terms
How it works
- The agent loop checks a set of conditions before each iteration, and the loop continues only while all of them hold. Conditions are evaluated by the harness, not by the model, which is what makes them binding.
- Task completion is the intended exit: the model stops emitting tool calls, or emits a designated final-answer call. This is the only condition whose firing means success, and it is the one the model controls.
- An iteration cap bounds the number of model turns. It is the simplest condition to implement and the easiest to misread, because a step count is not a cost.
- A budget condition tracks cumulative tokens or spend and halts when the ceiling is reached. This is the condition that actually bounds cost, since step cost varies by orders of magnitude depending on what a tool returns.
- An error or no-progress condition halts when repeated iterations fail or produce no state change — the same tool called with the same arguments twice is the usual signal that the model has stopped making progress.
- Each condition needs a distinct terminal state, because what happens next differs: completion returns a result, budget exhaustion returns a partial result and an explanation, and a no-progress halt should escalate rather than return anything.
Example: Why an iteration cap does not bound cost
A loop is capped at 20 iterations. A cheap step reads a 500-token tool result; an expensive one retrieves a 50,000-token document — a 100x spread in what one iteration can cost. A typical successful run takes 8 cheap steps and consumes about 8 x 2,000 = 16,000 tokens including the growing context. The worst case permitted by the iteration cap is 20 expensive steps, roughly 20 x 50,000 = 1,000,000 tokens: 1,000,000 / 16,000 = 62.5x the typical run, and entirely within the cap. A token budget of 100,000 bounds the same loop differently — it permits 50 cheap steps or 2 expensive ones, which is the behaviour you actually want, since the budget is the thing you are protecting. The two conditions are not alternatives: the cap stops a loop that is spinning cheaply and would otherwise run forever, and the budget stops one that is spending fast. A loop with only the cap has no ceiling on spend; one with only the budget can spin for a long time on cheap steps before it notices.
Commonly confused with
A stopping condition is not a timeout, and the two fail differently. A timeout bounds wall-clock time and fires regardless of what the agent is doing, including mid-tool-call, so it leaves the system in an indeterminate state. A stopping condition is evaluated at a loop boundary, so the agent is always between steps when it fires and the state is consistent and resumable. Production loops need both — a timeout for the hung tool call, stopping conditions for everything else — but a timeout alone gives you no ability to return a partial result, because you do not know where you were when it fired.
When to use it
Reach for it when:
- Any production agent loop, where the absence of a condition is an unbounded bill rather than a missing feature.
- Budget conditions specifically, whenever tool results vary in size, since that is when a step count stops predicting cost.
- A no-progress condition on loops with retry, which is where repetition without state change is the characteristic failure.
- Distinct terminal states per condition, so a caller can distinguish a completed task from an abandoned one.
Reach for something else when:
- An iteration cap alone on a loop whose tools return variable-size payloads — it bounds turns and not spend.
- A cap so tight that legitimate long tasks hit it, which converts a cost control into a correctness bug and is usually diagnosed as a model failure.
- Letting the model decide when to stop, unverified. Self-reported completion is a claim, and a loop that trusts it has no stopping condition.
- As a substitute for a timeout. A condition checked between steps cannot interrupt a tool call that never returns.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Stopping Condition — AI Glossary.
Frequently asked questions
What is Stopping Condition?
A criterion determining when an agent loop should terminate, either by task completion, error threshold, or resource limit.
What concepts are related to Stopping Condition?
Closely related concepts include max iterations, retry logic, agent.