Overview › 7Orchestration › b.Bounding execution › iii.
Size run budgets so productive runs aren't cut off: turn caps, deadlines, command timeouts
Control flow General
Set the turn or step cap, the wall-clock deadline and per-command timeouts from what runs that succeeded actually needed, not from framework defaults, so a run that is still making progress is not stopped short. This is one of three changes that bound a run, each for a different failure: this one lets productive runs finish, 7.b.i stops runs that have stalled, and 9.b.i makes sure a run that does hit the limit still returns its best answer. Raise a cap only together with 7.b.i, or a stall becomes a longer stall. Timeouts are tuned both ways: a timeout that kills commands that would have finished is too low, one that lets a hung command eat the run is too high.
Tier 2 because budgets are execution bounds.
When it applies
- In the code: caps, deadlines and command timeouts at framework defaults, unchanged since the agent was built
- In traces: runs ending at the turn cap or deadline while still producing new information in their last turns (a run that ends at the cap after repeating itself is 7.b.i's signal, not this one); commands killed by a timeout that finish when re-run with a longer one
- In eval results: limit-ended outcomes (turn cap, deadline, command timeout) on cases where the run was still progressing
How
- From traces, take the distribution of turns, wall-clock and command durations on runs that succeeded.
- Find the runs that ended at a limit while still progressing: new tool results, new files or a changing answer in their last turns.
- Set each cap above the successful range (for example the 95th percentile) and each command timeout above the longest command that finished, with 7.b.i in place before raising a cap.
- Re-run the truncated cases and compare limit-ended outcomes, cost and turns on the same cases.
How to measure it
- before after (tier 2): limit-ended outcomes, cost and turns on the same cases, before and after
To compare the change against your agent's current version, with the same cases and enough repeats to see past run-to-run noise, use aot-evals.
Expected impact
- Cost: mixed, medium: more turns per case when a cap is raised
- Performance: mixed, medium
Caveats
The evidence is frequency only: VeRO's optimizers raised turn caps far more often than they lowered them (MAX_TURNS 63 up, 14 down) and moved timeouts both ways, but no run measured the effect. Client retries for rate limits and transient errors are not a budget; they are in 2.b.i.
Evidence
Evidence comes from: Web research.
-
five follow-up benchmarks
MAX_TURNS raised 63 times, lowered 14; MAX_STEPS raised 26, lowered 5. The most-edited constants in the corpus.
Scale AI, VeRO code release · figure_04
-
five follow-up benchmarks
Turn-budget edits in 11 to 18 of 20 runs per benchmark.
Scale AI, VeRO code release · figure_01
-
GAIA
Knight 40 max turns vs Pawn 20.
Scale AI, "VeRO: A Harness for Agents to Optimize Agents" (ICML 2026) · Feb 2026 · paper Table 10
-
five follow-up benchmarks
SOFT_DEADLINE_SEC 2 up / 3 down, COMMAND_TIMEOUT_SEC 1 up / 4 down, RESEARCH_DEADLINE_SEC 0 up / 2 down. Direction is mixed, unlike turn budgets.
Scale AI, VeRO code release · figure_04
Related
- 7.b.iDetect stalls and loops: warn, then stop early
- 9.b.iMake the final answer reliably extractable: state the format, extract robustly, force an answer at the limit
- 2.b.iMake tool calls and tool results fail soft, and retry transient failures
- 5.a.iCompact conversation history in stages: elide stale tool outputs, then keep an anchored summary
- 7.d.iContinuous autonomous task loop
- 4.c.iEpisodic memory retrieval
- 7.c.iiiEvaluator-optimizer loop
- 8.b.iiLink large schemas by exploration: start broad, grow the linked set with probing queries, favor recall
- 6.b.iParallel tool execution for read-only calls
- 7.d.iiiReAct loop
In Claude Code
This optimization is a skill in aot-kit, our open-source Claude Code plugin: /aot-kit:size-execution-budgets. Its library entry holds every source. Have new evidence, or a correction? Suggest a change.