[BUG] Silent full transcript replay on cache expiry destroys rate budget on resume

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When a Claude Code session goes idle long enough for the server-side cache to expire, the next message replays the entire session transcript as uncached input — silently and without any warning.

On a 500K-token session idle for 7 hours, a single message consumed 9% of the 5-hour rate limit instantly — jumping from 0% to 9% before any real work was done. On 1M+ token sessions this could be 20-40% of the rate limit in one message.

The user receives no prompt, no warning, and no option to compact first. There is a message offering /clear to save tokens, but it doesn't explain why or what the cost of not doing it is.

This actively punishes the core use case of Claude Code — long, deep sessions that users leave open and return to.

What Should Happen?

Before replaying a stale session transcript above a token threshold, the user should be warned and given options:

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]

Or at minimum: auto-compact before replay if the transcript exceeds a threshold.

Error Messages/Logs

No error shown. Rate limit meter jumps silently on the first message after idle.

Steps to Reproduce

1. Start a Claude Code session with Opus (1M context)
2. Work normally for 30+ minutes to accumulate 200K+ tokens
3. Leave the session idle for 2+ hours (enough for cache to expire)
4. Send any message
5. Observe rate limit meter jump (9%+ on 500K token sessions)

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_N/A_

Claude Code Version

2.1.92 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Separately observed: sessions on devices with fewer dynamic hook injections (more stable context prefix) showed no rate spike on resume — suggesting the cache held longer when the prompt prefix is more stable. This implies the issue is worsened by volatile context prefixes (timestamps, status injections, etc.) that break the cache on every turn.

Empirical data from 2026-04-04.