Cache replay cost bomb on idle/resumed sessions

Feedback: Cache Replay Cost Bomb on Idle/Resumed Sessions

Filed: 2026-04-04
Product: Claude Code (CLI)
Severity: HIGH — silent budget destruction
Version tested: 2.1.91, Opus 4.6 (1M context)

---

The Problem

When a Claude Code session goes idle long enough for the Anthropic server-side cache to expire, the next message replays the ENTIRE session transcript as uncached input. On a 500K-token session idle for 7 hours, a single message consumed 9% of the 5-hour rate limit — from 0%.

This is silent. No warning. No confirmation dialog. The user sends "hey" and loses a tenth of their rate budget of those 5h. If that seems small, imagine what happens if user had a few terminals idle and then prompts them to look at the work he left them to do for the night.

On longer sessions of accumulated cache (1M+ tokens), this could be 20-40% of the rate limit in one message. A user resuming work the next morning loses a significant chunk of their budget before typing anything meaningful.

---

Observed Behavior

• 500K token session, 7 hours idle
• Single message sent
• Rate jumped from 0% to 9% immediately
• No prompt, no warning, no option to compact first
• There was a message about offer of /clear to save 276.6k tokens, not enough explanation to a user why or what it is.

Separately confirmed: a session on a device with minimal hooks (fewer dynamic injections) showed no rate spike on resume — suggesting the cache held longer when the context prefix is more stable.

---

Proposed Fixes (any combination)

1. Gate large replays with user confirmation

Before replaying a session where the cache has expired and the transcript exceeds a threshold (e.g., 100K tokens):

This session has 500K tokens of history and the cache has expired.
Resuming will replay the full transcript (~9% of your 5h rate limit).

[Resume] [Compact first] [Start fresh]

This is the minimum viable fix. The data exists server-side to compute this.

2. Auto-compact on stale resume

If the cache has expired AND the transcript exceeds a threshold, automatically trigger the built-in compaction before replaying. The compacted version is smaller, cheaper to replay, and achieves 80% of the context recovery.

Claude Code already has a compaction mechanism (auto-compact). Wire it to fire on stale resume as a pre-processing step, not just on context overflow.

3. Chunked session JSONL with turn-rate capping

The session transcript (.jsonl) grows unbounded. Claude Code already writes this file — it could chunk it at a defined turn interval (e.g., every 50 turns, start a new segment). On resume, only replay the most recent chunk + a compact summary of prior chunks.

This is how session snapshot systems work. Claude Code is already 90% of the way there with its auto-compact summarization. The missing piece is making the summarization happen at write time (proactive), not at overflow time (reactive).

4. Cache TTL transparency

Expose the cache state in the status bar or /status output:

Cache: warm (expires in 12m) | stale (expired 3h ago, 500K replay pending)

Users can't optimize what they can't see.

---

Why This Matters

Claude Code's value proposition is long, deep sessions. The cache expiry mechanism actively punishes this use case. Users who leave sessions open (the natural workflow — step away, come back, continue) get silently charged the full replay cost. The longer and deeper the session, the worse the penalty.

Max plan users at $100-200/month are the most affected — they run the longest sessions on the most expensive models. The March 2026 rate complaints on GitHub correlate with this: users reporting sudden rate spikes after "doing nothing" were likely hitting cache replay on stale sessions.

---

Reproduction Steps

1. Start a Claude Code session with Opus 4.6 (1M context)
2. Work normally for 30+ minutes (accumulate 200K+ tokens)
3. Leave the session idle for 2+ hours (cache expires)
4. Send any message
5. Observe rate limit jump

---

Empirical data from 2026-04-04.