Your token bill spiked.

An agent bill grows faster than the turn count because each turn resends the whole conversation, so cost rises roughly with the square of the conversation length rather than in step with it. The usual causes are a retry loop, an escalation spiral, and an unbounded context window, and all three look like normal operation in a dashboard that only plots total spend. On a measured 25-attempt loop the governed arm paid 4.1% of the ungoverned bill for the same number of attempts.

Why does the bill grow faster than the number of turns?

Each turn of a conversation resends every previous turn as input, so turn 20 pays for turns 1 through 19 again. Cost therefore grows with the cumulative length of the conversation rather than in step with the turn count, and input tokens dominate the total long before output tokens matter. That is why a loop that looks like a modest number of extra turns can be a large multiple on the invoice.

How do I find which agent run caused the spend?

Attribute spend per run before optimising anything, because an aggregate bill cannot distinguish one runaway from broad growth. Tag every upstream request with a run identifier, record prompt and completion tokens per call rather than per day, and sort runs by total input tokens. A runaway sorts to the top immediately and looks nothing like the rest of the distribution, which is the fastest confirmation available that the problem is one pattern rather than your whole workload.

Which patterns burn the most tokens?

Three patterns account for most surprise agent spend: a failed tool call retried verbatim, a demand paraphrased and cycled after a refusal, and an escalation spiral where each turn raises the intensity of the last. All three are repetition without progress, all three resend the full context every lap, and none of them terminates on its own, because nothing in the loop is aware that it is a loop.

Does switching to a cheaper model fix it?

Switching models changes the unit price and leaves the multiplier in place, so a loop that costs ten times what it should still costs ten times what it should. It is worth doing for baseline economics and it is not a containment measure. The measured spread supports both points. Across seven measured configurations spanning four model families on the same verbatim-loop battery, the governed arm paid between 4.1% and 20.2% of the ungoverned bill. The reduction from stopping the loop is larger than the difference between model tiers.

Source: Pre-registered receipts benchmark, 2026-07-19. Scored output of harness/report.py.

Does a spend cap solve this?

A spend cap is a backstop that fires after the money is spent, so it bounds the worst case for a month and does nothing for the incident. It also cannot tell a runaway from a busy day, which means it is set either low enough to interrupt legitimate work or high enough that a loop can run for hours underneath it. Caps and controllers are complementary: the cap bounds the ceiling, the controller stops the specific turn.

The longer answer on spend caps

How much of the spend is recoverable?

On the pre-registered receipts benchmark the governed arm paid 4.1% to 20.2% of the ungoverned bill on seven measured configurations across four model families in the verbatim-loop battery, with the largest reduction on GPT-5.6 Sol and the smallest on Claude Haiku 4.5. Both arms make the same number of attempts, so the spend delta is the whole measurement rather than a side effect of doing less work. That range is one battery, not a portable average for arbitrary workloads.

OpenRouter rows are the upstream's own metered usage.cost, not price-table token math. OpenRouter's meter matched price-table token math for Haiku (0.0%) and Gemma (12.6%) but flagged a 24% divergence on Llama 4 Scout (provider routing), so Scout's dollars are the upstream meter. The ratio is unaffected. Gemini-native Gemma is free-tier only, so those rows are token deltas and carry no dollar claim.

Source: Pre-registered receipts benchmark, 2026-07-19. Scored output of harness/report.py.

What does the governor itself cost to run?

The controller adds no upstream tokens, because it reads intensity, valence, repetition as numbers and never sends text of its own to the model. Its cost is local compute: one controller tick measured p99 2.8 µs in an in-process Python microbenchmark over 100,000 iterations: not end-to-end, not the wasm core, no network. End-to-end governed proxy overhead measured p50 1.2 ms and p99 2.4 ms. Those two figures are different measurements and are not interchangeable.

Source: Bench run 2026-07-18, latency_bench.py, Windows 11 AMD64, Python 3.14.5.

Read next

• Why your agent is looping
• Preventing runaway spend
• The full spend tables
• Every number and its qualifier

Every guide is listed on the guides index, and the short form of most of this is on the questions hub.