[BUG] 5-hour quota consumption jumped ~15-20x starting 2026-08-08, persists (previously intermittent + self-resolving); multi-instance Claude Code usage

[BUG] 5-hour quota consumption jumped ~15-20x starting 2026-08-08, persists (previously intermittent + self-resolving); multi-instance Claude Code usage

Summary

Since ~2026-08-08 my 5-hour session quota is being consumed at roughly 15-20x the rate I saw before that date, and the elevated consumption is now persistent across sessions instead of resolving after one 5-hour window. I run multiple concurrent Claude Code client instances and have done so continuously for ~3 months, so this isn't a new usage pattern on my end.

Related: #41930, #37436

Timeline (as I've observed it)

• Past 3 months: Running multiple concurrent Claude Code instances continuously — normal/unremarkable quota consumption.
• ~10-12 days ago until 4 days ago (~2026-08-02 to ~2026-08-08): Abnormal spikes occurred 2-3 times, each in a different instance, and each resolved on its own after one 5-hour window elapsed — consistent with a transient counter/cache desync rather than real extra work.
• From ~2026-08-08 (4 days ago) onward: The elevated consumption became persistent — no longer self-resolving after a 5-hour window.
• Estimated magnitude: usage now ~15-20x what the same kind of work consumed before 2026-08-08.

Concrete data from this session's debug log

Session: 194db65e-5c41-4351-98b4-b03667b8e261, 2026-08-12, Windows 11 Pro, Claude Code CLI (native install), model claude-sonnet-5.

CLI auto-updated mid-session: version_from=2.1.227 → version_to=2.1.228 at 2026-08-12T07:21:59.036Z.

Per-turn cost/token figures pulled directly from the debug log ([engine] turn N end lines):

| Turn | Input tokens (new) | Output tokens | Cost | API latency |
|---|---|---|---|---|
| 2 | 8 | 962 | $0.1949 | 22707ms |
| 3 | 519 | 3,915 | $0.3678 | 61834ms |
| 4 | 1,025 | 4,568 | $0.4232 | 74587ms |

Total: ~$0.99 in internal cost-equivalent across 3 conversational turns in ~3 minutes, for work that was primarily reading/grepping a single local log file and writing analysis back to the user — not proportionate to actual compute performed.

fetchUtilization: GET /api/oauth/usage was called at 2026-08-12T07:22:10.252Z, immediately after turn 2 ended (07:22:03.775Z), and the client's displayed 5-hour usage moved from 0% to 4% at that point — i.e., a single turn with 8 new input tokens and 962 output tokens registered as 4% of the 5-hour quota.

Why I believe this is server-side, not a client misconfiguration

• No local settings, CLAUDE.md, or workflow changes on my end coincide with 2026-08-08.
• I've used the same heavy-parallel-subagent workflow style for the full 3 months, including during the period before the problem started, so subagent fan-out isn't the driver.
• The problem's own behavior changed character on 2026-08-08 — from occasional, self-healing spikes (isolated to a single instance, resolved after 5 hours) to a persistent, universal elevation — which reads like a regression in server-side quota/cache accounting, not a change in my usage pattern.
• Multiple concurrent client instances have been my standard setup for 3 months without issue until the last ~10-12 days, and the multi-instance angle matches other reports of this behavior class.

Related existing issues

This looks like the same bug class as:

• #41930 — widespread abnormal usage limit drain across paid tiers, multiple root causes, no formal communication
• #37436 — abnormal quota consumption / rate_limit_error specifically with multi-session Claude Code
• #41171 — discrepant quota metrics across dashboard and CLI
• cache-invalidation regression described in cnighswonger/claude-code-cache-fix (up to 20x cost increase on affected sessions) — the magnitude reported there (~20x) matches what I'm seeing (~15-20x)

Environment

• OS: Windows 11 Pro (10.0.26200)
• Claude Code version: 2.1.227 → 2.1.228 (auto-updated during the session that produced the data above)
• Plan: Max (monthly paid subscription)
• Model: claude-sonnet-5
• Usage pattern: multiple concurrent client instances, ongoing for ~3 months

Request

Could someone confirm whether there's a known regression in 5-hour quota/usage-counter accounting (possibly related to prompt-cache invalidation or multi-instance session tracking) that started or worsened around 2026-08-08? Happy to share the full debug log for the session above if useful.