Mahal Systems

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

  1. From traces, take the distribution of turns, wall-clock and command durations on runs that succeeded.
  2. Find the runs that ended at a limit while still progressing: new tool results, new files or a changing answer in their last turns.
  3. 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.
  4. 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.

  1. 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

  2. five follow-up benchmarks

    Turn-budget edits in 11 to 18 of 20 runs per benchmark.

    Scale AI, VeRO code release · figure_01

  3. 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

  4. 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

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.

Before you go...

Build better agents, weekly

Our latest research, performance benchmarks, optimization strategies, and updates around AOT development.

One email a week, nothing else. Unsubscribe anytime.