[SEV-1] budget.spent() reports 72x under actual consumption - blew through my weekly budget in 4 hours. Escalate cost controls before this hits other users.

The pause is almost certainly the cause, and your own post-mortem numbers already show it.

Output 11.3M, cache-write 50.6M, cache-read 819.5M. Output is about 1.3% of the tokens that actually moved. Your per-agent 200K ceiling was measuring that 1.3%, so it was never going to fire no matter how far the run overran. Nothing was broken about the guard — it was watching the wrong quantity.

What the pause did: prompt caches have a short TTL (5 minutes by default, an hour on the extended option). A wait of "fewer than six hours" expires all of them. Before the pause, each agent's stable prefix was a cache read, billed at a small fraction of base input. After it, that identical prefix has to be re-ingested as a cache write — priced above base input — and then read again. Same workflow, same context, same code path, and the per-agent cost steps up by roughly the read-to-write ratio. That is the shape you saw: 36 agents cheap, short pause, remaining 14 at roughly 10x.

It also explains the silence. cache_creation and cache_read are separate token classes from output. If the ledger sums only output — or only what the tool surfaces — then the entire class that changed is invisible to it. No threshold crossed, no anomaly, no guard, right up until the account-level weekly meter catches up.

Two things that would make this observable:

• Track all four classes separately (input_tokens, output_tokens, cache_creation_input_tokens, cache_read_input_tokens) rather than collapsing to one number. Every API response reports them in its usage block; the failure mode is summing the wrong subset.
• Treat any resume-after-idle as a cache-cold run and expect the first pass over each agent's context to be charged at write rates. Note the perverse interaction here: a pipeline that pauses because it hit a quota will systematically resume into its most expensive possible configuration. The limiter and the cache actively fight each other.

The general trap, and the reason this class of bug is so quiet: a budget control that runs inside the thing being budgeted can only count what that thing chooses to expose. The number that actually gets billed lives at the API boundary.

One follow-up in case it helps close this out: you can confirm the cache-cold mechanism straight from your own usage data, no new instrumentation. Pull cache_creation_input_tokens for the 14 post-resume agents and compare them against the 36 that ran before the pause. If the post-resume agents show a large cache-creation spike where the earlier ones were almost entirely cache_read_input_tokens, that's the whole story — the stable prefix that was being read at a fraction of base input is being re-written at above base input. Which also sharpens the budget.spent() puzzle: it isn't so much miscounting as summing the wrong classes. Output stayed ~1.3% of the tokens that actually moved the whole time, so an output-based ceiling was always blind to the other ~98.7%. The pause didn't change what it was missing — it changed the price of what it was already missing, as that prefix shifted from cache_read (a fraction of base input) into cache_creation (above base input).

Two mitigations, depending on which cost you'd rather take:

• Don't let a run idle past the cache TTL. If it has to pause on a quota wall, the cheapest resume is one where the caches never go cold — chunk so no agent's context sits idle longer than the TTL (5 min default, 1 h on the extended option), or checkpoint-and-replay rather than pause-in-place.
• If a cold resume is unavoidable, price it as one. Re-estimate the first post-resume pass at cache-write rates and size the remaining budget against that, so the resume doesn't silently run at the wrong price.

Happy to compare notes if you end up rebuilding the accounting around the four token classes — from experience it's a sharp edge, and the fix is mostly where you put the counter, not how big the ceiling is.

This is a very useful failure report, especially the mismatch between the exposed budget signal and the token classes that actually consumed quota.

I'm building LLMCap as a provider-independent enforcement layer that blocks requests before they happen based on project, user, model, and run budgets. Your cache-read/cache-write example exposes an important requirement: a hard cap is only trustworthy if it accounts for the same dimensions the provider actually bills or uses for quota.

Would you be open to a short feedback exchange? In your workflow, would the most useful external control be:

1. a hard quota/cost stop before each call,
2. attribution showing which agent/run/token class caused the burn, or
3. both, with a recoverable pause rather than terminating the session?

Demo, if useful: https://app.llmcap.io/demo

No generic sales pitch -- I'm trying to validate the enforcement boundary against real failures like this one.