[Bug] Excessive token consumption rate during normal operations

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68901
2. https://github.com/anthropics/claude-code/issues/56441
3. https://github.com/anthropics/claude-code/issues/42249

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Update with client-side data contradicting the meter — this is a recurring, reproducible pattern, not a one-off.

I hit the 5-hour session limit (not the weekly one) typically in under an hour of active use, repeatedly. Today is a representative case, and notably one of my lightest days by my own client ledger.

My Claude Code stats-cache.json records today as 5.4M Opus-4.8 tokens, 4,347 msgs, 30 sessions — among my lowest of the week — yet the 5-hour window filled in well under an hour.

Exact trailing-5h local consumption at the moment the limit triggered:

• Messages: 381 (single project, mostly Opus 4.8)
• Raw input: 97k · cache_write: 1.44M · cache_read: 34.0M · output: 288k
• Total all token types: 35.8M; cache-weighted cost proxy (cache_read ×0.1, write ×1.25, output ×5): ~6.7M

On a 20× Max plan, ~6.7M weighted tokens consuming the entire 5-hour window — in under an hour — implies a ~10–20× metering discrepancy. ~95% of the raw volume is cache_read, which should bill at ~0.1×; the numbers are consistent with cache_read being metered at or near full rate. costUSD is 0 in modelUsage locally (subscription plans don't log cost client-side), so the spike exists only server-side with no local counterpart.

No cloud/web/scheduled/background runs were involved — all consumption is local and accounted for above.

Repro: run a heavy-prompt-cache session on Opus (large system prompt + many MCP servers/skills re-read each turn); the 5h limit trips at a small fraction of the expected token budget, consistently within an hour. Feedback ID: c568757a-e001-4aed-b2a1-3358b2a760b4.

/usage panel at the time of limit (5-hour bar full):

[screenshot: /usage showing the 5-hour limit at 100% with reset timer — attach here]

Happy to share the stats-cache.json excerpt on request.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.