The budget your bill is missing is the one set against a number, because the spend is not a number. A chat completion is close enough to a fixed weight: the prompt is known, the output is capped by the max-tokens setting, and the price is the rate card's. An agent task is a compound object: a loop in which the model writes, reads the tool output, rewrites, reads again, and sometimes abandons and restarts. The loop length is not a setting, it is a result, and the token spend is the sum of a variable-length loop at the rate card's prices. The budget question changes from "what will it cost" to "what is the shape of the cost," and the shape is the distribution, not the number.
The 1000x, and the spread that is the actual fact
Recent measurement of agentic coding workloads (arXiv 2604.22750) puts an agent's session at roughly 1000x the token spend of a comparable chat. The number that does the work in the budgeting frame, though, is not the mean, it is the spread: a well-scoped task lands at a few thousand tokens, and the same phrasing on a difficult repository, or against an under-specified goal, lands ten times higher, on the same model, the same day, the same account. Two properties follow straight. The median of a month (and often its P90) underestimates the bad week. And the distribution has a fat tail, it does not normalize, and in the tail the mean and the variance lie while the quantiles do not.
The overbooking frame: what the airline actually prices
Airlines do not overbook at "average no-show plus a little cushion." They price the no-show as a distribution, overbook against the quantile that keeps the denied-boarding probability within tolerance, and manage the tail with standing rebooking rules rather than arithmetic. Agent spend is the same-shaped problem: there is the inventory (the monthly credit), there is the demand (agent workloads, which are stochastic), and a budget set at mean plus one standard deviation breaks on exactly the weeks that matter. The standard quantiles, applied here:
- P50 - the good-week line. It is the reporting number, not the cap.
- P90 - the working budget for interactive work.
- P99 - the line for autonomous, unattended runs. The tail lives here, and the loops live here, and the line is sized for the loops.
The stop-loss: the cap that spans the retry
A per-request rate limit is the wrong instrument, because the unit of compound work is the task, not the request, and a cap that is per-request is a cap the loop can walk through. The cap that works is per-task, spanning the whole run, and it sits in a nested structure:
- The per-task cap - a hard token ceiling on a single agent run, set at roughly P99 x 1.2 for the task's class. When it trips, the run stops, returns what it has, and flags. The stop-loss is the stop, not the alert - the alert is the control the tail absorbs, and the stop is the one it cannot.
- The per-day envelope - across total autonomous spend, so fifty bad tasks do not compound into one day's loss. The envelope is the position limit, the way the task cap is the stop.
- The per-project monthly - the customer-visible bill, and the lines above are managed against it.
The failure mode to look for is the soft-forever loop: a task that retries, fails, and retries again, each attempt inside its per-request budget and the total outside every task budget. A cap that is per-request is a cap the loop can consume forty times. The cap that spans the retry is the one that holds, and the spanning is the design decision, not the default - several stacks apply budgets at the request layer by default, and the loop is the thing the request layer cannot see.
What to do
- Instrument every run at the task layer: tokens in, tokens out, round trips, tool calls, terminal state. The instrumentation is the pricing, the same as in the anatomy of an agent invoice, and the direction is backwards - you measure first, and budget from the measurement.
- Label your task classes (scoped execution, implementation, debugging, documentation) and compute P50 / P90 / P99 per class from a month of data before setting any cap. The cap set before the distribution is measured is a guess; the cap set after is a number.
- Set the autonomous budget at the class's P99 with a stated multiplier, and the interactive budget at P90 - and the class is the variable, because the class is what the budget is per.
- Make the per-task cap span the retries, and make the behavior at the cap a stop rather than an alert, because the alert is the control the tail can absorb and the stop is the one it cannot.
- Check your harness's own limits before the model's: the coding agent limit is often the constraint that bites first, and a budget that exceeds the harness's ceiling is enforced by the harness, with the harness's error, not your cap's flag.