Your token bill spiked.

01

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.

02

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.

03

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.

04

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 model families on the same verbatim-loop battery the governed arm paid between 4.1% and 20.2% of the ungoverned bill, so 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.

05

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.

06

How much of the spend is recoverable?

On the pre-registered receipts benchmark the governed arm paid 79.8% to 95.9% of the ungoverned bill across seven model families on 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 our token math. OpenRouter's meter matched our 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.

07

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 as an in-process microbenchmark over 100,000 iterations, and 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.