[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.

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 2 comments · opened Aug 1, 2026

Bug Description
Severity

Critical — quota accounting and cost-control failure

Summary

We ran a tested, instrumented pipeline across 36 of 50 agents. That completed 72% of the project while consuming only approximately 3–4% of the weekly Max quota.

The pipeline had already proven that its cost controls worked:

200K token limit per agent
Hard abort checkpoints
Runaway guards
Per-agent spend ledger
Concurrency-aware accounting
Multiple successful production runs

We then reached the weekly utilization limit, waited only a few hours—likely fewer than six—and resumed the same pipeline.

Nothing material changed in the workflow.

The remaining 14 agents then consumed approximately 20% of the weekly quota in about four hours—more than 10 times the expected consumption.

Every agent still reported below the 200K limit.

No budget threshold was exceeded.

No guard fired.

No anomaly appeared in the ledger.

The only indication was the account-level weekly utilization meter after the quota had already been consumed.

Core Bug

Claude Code’s workflow-visible budget accounting did not reflect the consumption being charged against the weekly Max quota.

The pipeline believed every agent was under its 200K ceiling, while the platform was consuming quota at a radically higher rate.

This made every cost control ineffective despite the controls having already been validated across 36 successful runs.

This is not a forecasting error or an untested workload. A previously proven process became more than 10 times as expensive after a short pause, with no observable signal explaining why.

Evidence

Before the pause:

Agents completed: 36 of 50
Project completed: 72%
Weekly quota consumed: approximately 3–4%
Per-agent limit: 200K
Budget violations: none

After resuming:

Agents remaining: 14 of 50
Weekly quota consumed: approximately 20%
Elapsed time: approximately 4 hours
Per-agent limit: 200K
Reported violations: none
Runaway guards fired: none

Post-mortem session accounting showed approximately:

Output tokens: 11.3M
Cache-read tokens: 819.5M
Cache-write tokens: 50.6M

The exposed budget controls appeared to track output-token usage, while weekly quota consumption was dominated by token classes the pipeline could not see or constrain.

Suspected Failure Boundary

Something changed between the validated run and the resumed run, potentially involving:

Prompt-cache reuse
Cache expiration and context rewriting
Model or routing behavior
Concurrency handling
Token accounting
The data supplied to budget.spent()

The important fact is that platform-side consumption changed dramatically while workflow-side accounting did not.

Expected Behavior

A 200K hard limit should prevent an agent from consuming materially more than its configured budget.

If weekly quota is calculated using input, output, cache-read, and cache-write consumption, the budgeting interface must measure those same categories.

A previously validated pipeline should not become more than 10 times as expensive without:

Triggering a budget limit
Producing an anomaly warning
Showing an increased live burn rate
Requiring confirmation before proceeding
Exposing which consumption category increased
Actual Behavior

All 14 resumed agents remained below the reported 200K limit, yet together consumed approximately 20% of the weekly Max quota.

Claude Code provided no warning, abort mechanism, or accurate in-process measurement.

Required Fixes
Make budget limits use actual quota consumption, including input, output, cache-read, and cache-write tokens.
Clarify or rename budget.spent() if it measures only output tokens. The current name implies total spend.

Add a quota-based hard stop, for example:

Abort this workflow after consuming 2% of my weekly quota.

Expose a live weekly-quota burn meter during agent and fan-out execution.
Warn before resuming a large or cache-expired session, including an estimate of the initial cache-write cost.
Record model, routing, cache, and accounting changes so a sudden cost regression can be diagnosed.
Impact

A user implemented every available safeguard, validated those safeguards across 72% of a real workload, and then watched the same process consume approximately 20% of a weekly allowance without any control detecting it.

The absence of an accurate budget signal means users currently have no reliable way to prevent this class of runaway quota consumption.

Other Max users may have experienced the same failure without realizing why their weekly allowance disappeared.

Environment Info

  • Platform: linux
  • Terminal: cursor
  • Version: 2.1.220
  • Feedback ID: bc61e23b-a08e-47fa-a8ef-b942bc84d0e3

Errors

[]

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗