Disproportionate subscription usage burn in long sessions: cache TTL expiry re-writes + no usage attribution in /usage
Usage consumption report — session c4ecb168-70cc-43aa-af5c-d8ccfe4bcadd
Summary: ~15% of my session usage limit was consumed in ~2 hours during which I sent only a handful of short messages, and another jump to ~50% followed with near-zero interaction. Token ledger from local logs (~/.claude/projects/*/c4ecb168*.jsonl) explains the mechanics, but the resulting burn rate feels disproportionate for a subscription user.
Measured (last 6h, single session, model claude-fable-5, 173 API calls):
| hour (local) | calls | input | output | cache_write | cache_read |
|---|---|---|---|---|---|
| 17h | 51 | 36,581 | 68,420 | 1,423,501 | 17,022,244 |
| 18h | 28 | 4,040 | 20,142 | 1,198,250 | 10,070,714 |
| 19h | 34 | 25,354 | 48,681 | 482,929 | 13,843,698 |
| 22h | 37 | 1,170 | 38,571 | 529,647 | 16,541,872 |
| 23h | 23 | 29,404 | 27,741 | 129,420 | 4,352,757 |
| Total | 173 | 96,549 | 203,555 | 3,763,747 | 61,831,285 |
What drove it (as analysed in-session):
- Long-running session (~450k-token context pre-compact). Every tool round-trip re-reads the full context; 60 calls in 22h–23h alone ≈ 20.9M cache-read tokens from ~6 short user messages.
- Prompt cache TTL of 5 minutes: idle gaps between messages expire the cache, forcing full context cache re-writes (3.76M tokens at 1.25× pricing across 6h) — the user pays a premium for pauses.
- Cache reads, though discounted, still count toward the usage limit; at this context size the discount doesn't prevent rapid quota depletion.
/compactitself consumed a large one-time chunk (full-transcript summarisation pass).
User impact / feedback:
- The usage meter offers no attribution — the user saw 32% → 47% → 50% with "nothing open" and no way to tell what consumed it. Per-session or per-cause breakdown in
/usagewould prevent this alarm. - Charging premium cache re-writes because the user paused for 5 minutes punishes normal interactive usage in long sessions.
- Suggestion: surface a warning when a session's per-turn cost crosses a threshold (e.g. "this conversation now costs ~450k tokens per message — consider /compact or a new session").
Plan: Claude subscription (Fable 5 access). Date: 2026-07-12. Platform: Claude Code CLI, macOS.
3 Comments
Reproduced here as well.. and 2 more people on discord saying the same.
Seeing the same mechanism from a different angle. When I actually broke my own week down, resume/startup overhead — re-establishing state after a cache/context expiry, before any task work starts — was eating roughly 20% of a session by itself. A second, separate ~20% was going to writing handoff/internal docs between sessions rather than the work I'd asked for. Neither shows up anywhere in
/usageas its own line item, which matches exactly what you're describing — the burn is real, it's just unattributed.Full breakdown with timestamps, if useful: https://github.com/anthropics/claude-code/issues/76987#issuecomment-4980746625
Independent confirmation with the root cause identified: the 1h prompt-cache TTL was removed in 2.1.218. Your symptom (5m TTL → cache re-writes → usage burn) is the direct consequence.
Measured across 236 sessions (2.1.215 to 2.1.222) with a drop-detection script (dedupe by consecutive same-
cache_read+ same-model records; drop =cache_readdecreases between adjacent deduped records):The 1h→5m switch costs 13.8% of total session cost — that's the gap-5-to-60-min drops that force full 5m rewrites, which a 1h TTL would have absorbed as cache_reads. On 2.1.220 alone (83 sessions, 325 such drops), it's 16.6%.
Your "20% resume/startup overhead" observation aligns with this: the 5m TTL makes every 5+ minute gap (user idle or agentic tool call) a full rewrite, and the rewrite cost is what shows up as disproportionate burn.
Filed as #84253 with the full version-by-version breakdown.
✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)