A step budget caps how far a run can go. Because a ReAct loop chooses its own next action, an unbounded loop is an unbounded cost — budgets are what make agent spend predictable.
Not one budget, several
The most important thing to understand is that these are independent, not a single shared pool:
- An overall step ceiling for the run
- A separate cap on transfers
- A separate cap on successful delegations
- A hop-depth ceiling for cross-agent chains, plus cycle detection
Running out of any one of them ends the run. A run can terminate with transfer_limit_exceeded while nowhere near its step ceiling.
Only completed work counts
A delegation consumes budget only if it actually dispatches. Skipped or failed targets do not count against the cap. This means a run that repeatedly fails to reach a target will exhaust its step budget rather than its delegation budget — a useful diagnostic signal.
Nested budget decay
Cross-agent calls get a reduced step budget proportional to how deep the chain already is. A chain within the legal hop depth therefore still cannot multiply total work indefinitely: each level has less room than the one above it.
This is why a workflow that works standalone can behave differently when invoked as a nested agent-to-agent call — it is running with less budget than it had on its own.
Tuning
When a run hits max_steps_exceeded, raising the ceiling is the obvious move and usually the wrong first one. It is more often a signal that the routing graph is doing too much hopping — a triage sub-agent that transfers instead of delegating, or specialists consulting each other in a chain that could be a fan-out. Simplify the graph first; raise the budget when the graph is genuinely irreducible.