Stop conditions & step budgets
Rules that end an agent loop: task done, or a cap on turns, tokens, time, spend, repeated actions or errors — each with a logged reason.
Stop conditions tell an AI agent when to stop. The good ending is "the task is done". But agents can get stuck repeating a failed step, or wander for an hour, so you add hard limits: a maximum number of steps, a time limit, a spending limit.
Without them a confused agent can loop for a long time and run up a real bill.
A search party's orders: come back when you find them, at sunset, or if the weather turns — whichever comes first.
Only a turn cap. Turns vary wildly in token cost, so a run can stay under 30 turns and still burn $20; cap tokens, time and spend too.
Two families. Success exits: the model returns a final answer with no tool call, calls an explicit finish tool with a structured result, or an external check passes (tests green, schema valid). Safety exits: caps on turns, cumulative tokens, wall-clock and $; no-progress detection (same tool + same arguments N times, or no state change across K turns); error budgets (consecutive tool failures); and policy trips from Guardrails. Frameworks ship a turn cap by default — OpenAI's Agents SDK uses max_turns = 10 and raises MaxTurnsExceeded — but turns are a poor proxy for cost.
Each exit should log a distinct stop_reason and degrade gracefully: a partial answer, a summary of what was tried, or escalation via Handoffs between agents or Human in the loop. Set caps from observed distributions (just above the p99 of successful runs), not guesses, and alert when cap-hit rates rise — it is often the first sign of a model, prompt or tool regression.
Turn cap ≈ 1.3× p99 of successful runs; token and $ caps likewise; wall-clock cap; repeat detector (3 identical calls); error budget (3–4 consecutive failures); explicit finish tool with a result schema; stop_reason enum logged on every run; graceful partial-result template.
Legal research agent over case law. Successful runs: median 8 turns, p99 22, p99 cost $0.85. Caps: 30 turns, 200k tokens, 12 minutes, $1.50, abort after 3 identical calls or 4 consecutive tool errors. A run that keeps fetching a court site returning 503 is stopped at the third identical fetch, returns "source unavailable — partial memo attached", and logs stop_reason=repeat.
List both families and say what the user sees when each fires. Recommend caps derived from the p99 of successful runs plus a $ cap, because turns vary 10× in cost.
Expect: "a cap is cutting off legitimate long tasks" — look at the stop_reason distribution by task class and give that class its own budget, or checkpoint and continue with approval.
| Condition | Type | Example limit | On trigger |
|---|---|---|---|
| Final answer / finish() | Success | — | Return result |
| Check passes | Success | Tests green | Return result |
| Max turns | Safety | 30 (p99 22) | Partial + summary |
| Token / $ budget | Safety | 200k / $1.50 | Partial + summary |
| Wall-clock | Safety | 12 min | Checkpoint, escalate |
| Repeat / no progress | Safety | 3 identical calls | Abort, log reason |
| Error budget | Safety | 4 tool errors in a row | Abort, alert owner |
| Guardrail trip | Policy | Blocked action | Escalate to human |
Numbers worth knowing
- OpenAI Agents SDK default
- max_turns = 10as of Oct 2026
- Cap setting rule
- ≈1.3× p99 of successful runsper task class, recomputed monthly
- Healthy cap-hit rate
- < 2–5% of runsabove that, a regression or mis-sized cap
How to decide
| When | Do this |
|---|---|
| You have no run data yet | Start strict (20 turns, $1, 10 min) and loosen from observed p99. |
| One task class legitimately runs long | Give it its own budget instead of raising the global cap. |
| A cap fires mid-task with partial progress | Checkpoint and offer continue-with-approval, not a silent failure. |
Cost maths
Expected loss from a missing $ cap = P(runaway) × runaway cost. If 0.5% of 40k monthly runs loop to a 300-turn limit at ≈ $25 each, that's 200 × $25 = $5,000/month of waste; a $1.50 cap bounds it at 200 × $1.50 = $300. Worst case per run becomes predictable: $1.50 × runs.
Operating it
- Cap-hit rate rises above 5% after a deploy
- A single stop_reason (e.g. repeat) doubles week over week
- p99 successful run cost approaches the $ cap
- stop_reason distribution (alert if any safety reason > 5% of runs)
- Hourly spend vs baseline (alert at 3×)
- Runs ending without a stop_reason (alert on any — a crash path)
- p99 cost of successful runs vs the $ cap (alert at 80%)
When it goes wrong
Weekend spend on a research agent hit $9,000 against a $600 weekly norm.
Provider billing alert on Monday; the agent had no internal spend alarm.
A search API changed its error format; the tool returned the raw error page as a "result", the model kept re-querying, and the only safeguard was a 200-turn cap — each turn re-sending a 150k-token context.
$2 and 300k-token caps per run, repeat detection, tool errors as typed is_error results, and an hourly spend alert at 3× baseline.
Related terms
Where it shows up
Sources
- Running agents (max_turns) — OpenAI Agents SDK, 2025docs
- Building effective agents — Anthropic (Schluntz & Zhang), 2024blog
Check yourself
Three questions. Every option is explained once you answer.