Budgets: Time, Tokens, Tool Calls, Blast Radius

Budgets are the last line in this book's defence, and the only one that works when everything before it has failed. A run with no ceiling does not stop when it goes wrong. It continues, competently, until something outside it intervenes.

Key takeaways

• Four ceilings, not one: wall-clock time, tokens, tool calls, and blast radius counted in affected entities. Each bounds a different kind of damage and a token budget bounds none of the others.
• Blast radius is the ceiling that protects other people. Cap the number of external entities a run may touch, enforce it in the tool rather than the prompt, and batch work so a wrong decision reaches ten records instead of four hundred.
• Every ceiling needs a defined behaviour on contact, written in the plan artifact. The default should be pause and escalate, because terminating a run destroys the context the human needs.
• Budget per step as well as per run. A single step that consumes the run's whole allowance is a failure mode of its own, and it is invisible to a run-level ceiling until it is too late.
• Set the numbers from measured runs rather than intuition, and treat a run that repeatedly hits the same ceiling as a design finding rather than a limit to raise.

Read this beside Chapter 3, which carries the per-step budget field, and Chapter 10, which designs the escalation these ceilings trigger. Chapter 11 measures the distribution the numbers should be set from.

The run has been going for six hours. It is on its fortieth revision of a plan that originally had twelve steps, each revision triggered by a tool error it does not understand, and it has spent more than the task was worth somewhere around hour two.

Nothing is broken. Every component behaves exactly as specified. No individual step looks unreasonable, which is why nobody has stopped it.

Why an unbounded loop is the real risk

The intuition is that a failing agent stops. The observed behaviour is that it continues.

The reliability framing published in March 2026 gives this shape a name with its meltdown onset point, and reports variance amplification as horizons lengthen, with high variance correlating with capability rather than with instability. The operational translation is uncomfortable: the more capable system produces the wider distribution of outcomes, including the long confident excursions that cost the most.

Chapter 2 explained the mechanism. A wrong intermediate state is inherited rather than detected, so every subsequent step is well executed and pointed the wrong way. Nothing in that loop generates a stop signal, because from inside the run everything is working.

So the ceiling is not a pessimistic guess about the agent's competence. It is the only component in the architecture whose job is to end a run that believes it is succeeding.

The four ceilings

Each bounds a different quantity, and a system with only one of them is unbounded in three directions.

The fourth is the one most systems lack. Tokens and time are easy to meter because a platform reports them. Entities affected has to be counted by your own code, which is precisely why it gets skipped, and it is the only ceiling that limits harm to somebody else.

Count it in the units a person would recognise. Customers contacted. Records modified. Files published. Payments initiated. Not requests, and not rows, because neither of those is what an incident report will be measured in.

Blast radius, enforced where it cannot be argued with

A limit stated in a prompt is a request. A limit enforced in the tool is a control, which is the same distinction Chapter 8 draws about destructive operations.

Implement it in three places at once. In the tool, as a hard cap per call that returns an instructive error above the limit. In the runtime, as a running count per run across all tools, checked before dispatch. And in the plan, as a declared expected scope, so that a run intending to touch ten entities and reaching forty is stopped by the discrepancy rather than by the absolute ceiling.

That third check catches what the other two cannot. A run whose scope was wrong from the start stays under an absolute cap while still being entirely wrong, and the expectation is what makes the wrongness visible.

Then batch. A step that would affect four hundred entities becomes forty steps of ten with a gate between them, which converts an unbounded error into a bounded one, and it gives the ceiling somewhere useful to bite. The Model Context Protocol's requirement that hosts obtain explicit user consent before invoking a tool sits naturally at this boundary: consent per batch is workable, while consent per record is not.

What happens when a ceiling is reached

An unhandled ceiling is a crash with extra steps. The behaviour belongs in the plan artifact, decided in advance, per ceiling.

Pause and escalate should be the default for three of the four. The run stops dispatching new work, completes or compensates anything in flight, checkpoints, and hands to a human with the record attached. Chapter 10 covers what that handoff must contain.

Hard stop belongs to blast radius alone, and only in its absolute form. A run that has touched more entities than it was ever permitted to touch should not wait for a human before stopping, because the thing being bounded is damage to other people.

Two mistakes recur. Terminating without a checkpoint, which throws away exactly the context needed to decide what to do, and is the most common implementation of "we have a timeout". And auto-extending, where the run asks for more budget and grants it to itself, which is the same as having no ceiling with additional logging.

There is a subtler decision about in-flight work. A run that hits a time ceiling mid-step should finish the step where the step is reversible and abandon it where it is not, because an abandoned irreversible step leaves the worst state available: an effect emitted, unrecorded and unreviewed.

Budget per step, not only per run

Run-level ceilings are necessary and insufficient, because they only fire after most of the damage is possible.

Give each step its own allowance for time, tokens, tool calls and retries, sized from what that step normally consumes. A step that usually takes twenty seconds and is still running after five minutes is not slow, it is stuck, and the run should treat that as a failure rather than waiting for the run-level ceiling an hour later.

Per-step ceilings also catch the retry interaction from Chapter 7. Six attempts with exponential backoff can hold a step open far longer than anyone intended, and the per-step wall-clock cap is what makes that visible.

There is a cheap derived signal worth adding here. Track the plan-revision count from Chapter 3 as its own ceiling. Runs that revise their plan repeatedly are thrashing, and revision count is usually the earliest budget to fire on a run that is going wrong, which makes it the most useful escalation trigger in the set.

Concurrency is the ceiling you forgot

Everything so far bounds one run. Production runs many, and the budgets that hold individually can fail collectively.

Twenty runs, each permitted to touch fifty records, is a thousand records. Each run is inside its ceiling. The system is not. The same arithmetic applies to spend, to rate limits on a shared provider, and to the poor database that receives all of it at once.

Three fleet-level controls cover it. A concurrency cap on runs of the same task family, so that a bad deployment produces one incident rather than twenty. A shared blast-radius budget per time window across all runs, checked before dispatch, which is the only control that catches correlated damage. And a circuit breaker: when the failure rate across a task family crosses a threshold, stop starting new runs of it.

The circuit breaker matters most during exactly the incident you would least like to amplify. A provider degrades, every run starts failing the same way, and without a breaker your system responds by retrying at scale. That is how a partner's bad hour becomes your bad week.

Setting the numbers, and reading them later

Numbers pulled from intuition are either so loose they never fire or so tight they fire constantly and get raised until they never fire.

Set them from measured runs. Take the distribution of successful runs for a task family, and set the ceiling somewhere in the tail rather than at the mean, so normal variation does not trip it. METR's Time Horizon 1.1 measurements from January 2026 are a reminder that the tail on long-horizon work is wide: their intervals span factors of four, and your own distribution will not be tighter.

Google's error budget framing gives the language for the trade. Decide the failure and interruption rate you are willing to carry, then set ceilings that keep you inside it, and treat the ceilings as a policy that product and engineering agree rather than as a setting an engineer chose.

Then read the data the ceilings produce. A ceiling that fires on 20% of runs is telling you something about the design rather than about the limit: the task is misspecified, a tool is unreliable, or the decomposition is wrong. Raising it converts a visible failure into an invisible cost, which is the worst available trade and the most common one.

Chapter summary

An unbounded agent loop is a liability because a failing run continues rather than stopping, and the 2026 reliability work's meltdown onset and variance amplification describe exactly that behaviour, with the more capable systems producing the wider and more expensive tails. Four ceilings bound four different quantities: wall-clock time, tokens or currency, tool calls, and blast radius measured in the external entities a run may touch, and only the fourth limits harm to other people, which is why it is both the most important and the one most systems lack. Enforce blast radius in the tool as a hard cap, in the runtime as a running count, and in the plan as a declared expected scope, since a run whose scope was wrong from the beginning stays under an absolute cap while being entirely wrong, then batch the work so consent and gates have somewhere to sit. Define the behaviour on contact in advance: pause and escalate for three of the four, hard stop for absolute blast radius, never terminate without a checkpoint and never let a run extend its own budget, with in-flight steps finished when reversible and abandoned when not. Budget per step as well as per run, because a stuck step should fail in minutes rather than at the run ceiling an hour later, and add plan-revision count as a ceiling of its own, since it is usually the earliest signal that a run is thrashing. Bound the fleet as well as the run, with a concurrency cap, a shared blast-radius budget per window and a circuit breaker on task-family failure rate, because twenty compliant runs can be one non-compliant system. Set every number from the measured distribution of successful runs rather than from intuition, and read a frequently firing ceiling as a finding about the design rather than as a limit to raise.

Three of the four ceilings end with a human being asked to take over. That handoff is where most agent systems are weakest. Chapter 10 is Handing Control Back to a Human, which is about escalation as a designed path rather than an exception: what the message must contain, who receives it, and why an escalation that arrives without the record is worse than no escalation at all.