The pattern that finally stopped my runaway bills: a budget envelope around every single run, set before the first tool call fires. Not a dashboard alert, not a monthly rollup — a number the runner itself enforces. Four steps, and the first three cover nearly all of the protection you need.
Why per run? Because runaway spend happens per run. A loop that burns $700 in 72 hours does it one tool call at a time, inside a single execution. Per-month dashboards only tell you the house burned down. Per-step counting lets you feel the smoke — and per-run envelopes let you kill the fire.
Envelope first¶
Every run gets a token budget before it starts — mine default to 16k tokens for standard tasks, more only for batch builds. The budget travels with the run state, and the runner itself enforces it. This is the crucial distinction: the envelope is not an alert threshold that pages someone, it is a constraint the execution layer cannot exceed. A dashboard alert tells you the run overspent; an envelope prevents the run from overspending. Set the budget when you define the task, because budgets assigned after the fact are just obituaries.
Count per step, not per month¶
Log input and output tokens on every model call against a small pricing table, and decrement the envelope with each step. This gives you cost as a live signal during the run, not as a forensic exercise afterward. Per-step counting also reveals the failure signatures of a runaway: token usage that accelerates, retries that multiply, tool calls that repeat with no progress. You cannot manage what you measure only monthly — and you cannot stop what you cannot see in real time.
A watchdog with teeth¶
When the envelope hits zero, the run is killed — and the reason is logged. A human-readable "killed at budget cap" entry is worth ten graphs. The kill must be unconditional: no "just one more call," no escalation flow that the agent can invoke, no retry that quietly resets the counter. Fail closed, always. The watchdog's job is to be the thing that says no when every other component in the system is inclined to say "keep going."
Reconcile on restart¶
If a run dies mid-way — and it will — the restart checks what already executed before spending a single token on redoing it. Never re-pay for work that is already done. Reconciliation against completed steps is both a cost control and a correctness control: re-running completed work wastes money and can produce duplicate side effects. The restart reads the record, skips what is done, and spends only on what remains.
The takeaway¶
The $700-in-72-hours horror story happened with no envelope at all — a loop kept calling tools with nobody counting. Observability dashboards showed the money leaving; nothing was armed to stop it. The envelope changes the outcome: a per-run budget, counted per step, enforced by a watchdog that kills at zero, with reconciliation on restart so you never pay twice. Steps one through three are the system. Step four is the discipline that keeps it honest.