Prompt cache dropped every ~40s in large sessions: full ~950k context re-written at 2x cost (v2.1.222)

Product: Claude Code (Desktop app, Windows)
Version: 2.1.222
Model: claude-opus-5
Date observed: 2026-08-09, 21:32–22:22 local (UTC+2)
Severity: High — burned ~50 % of a 5-hour usage window in ~50 minutes with 5 user prompts.

---

Summary

In a long-running session (~950k token context), the prompt cache is repeatedly invalidated
down to a fixed 38,701-token prefix, even though the cache was written with a 1-hour TTL
(cache_creation.ephemeral_1h_input_tokens) and the previous request 33 seconds earlier
had a successful 966,002-token cache read.

Each invalidation forces a full re-write of the entire context — ~950,000 tokens at
cache-write price (2× input). One such request costs roughly the same as 19 normal
requests in the same session.

This is not user behaviour. No prompt, no file edit, and no tool call precedes the drop in
any consistent way; normal requests continue to hit the cache immediately afterwards.

---

Evidence

Extracted from the session transcript
(~/.claude/projects/<project>/2c04c713-….jsonl), deduplicated by requestId.

Cache read collapses to exactly 38,701 every time — the system-prompt/tools prefix —
while everything after it is re-written:

| Gap since previous request | previous cache_read | this cache_read | this cache_creation |
|---:|---:|---:|---:|
| 33 s | 966,002 | 38,701 | 928,286 |
| 54 s | 966,987 | 38,701 | 929,584 |
| 36 s | 38,701 | 38,701 | 935,727 |
| 35 s | 985,576 | 38,701 | 947,943 |
| 42 s | 987,855 | 38,701 | 950,174 |
| 61 s | 993,202 | 38,701 | 955,493 |
| 39 s | 38,701 | 38,701 | 955,999 |

All of these were written as ephemeral_1h, i.e. cache_creation.ephemeral_5m_input_tokens = 0
and cache_creation.ephemeral_1h_input_tokens = <full amount>. A 1-hour entry should not be
gone after 33 seconds.

Two more sessions on the same machine show the identical signature (dddbf786… at ~660k
context, 280e1c17… at ~570k), so it is not specific to one conversation.

Impact (measured)

Window: last 50 minutes, all local sessions, deduplicated by requestId.
Effective tokens = input + 0.1 × cache_read + 2 × cache_write + 5 × output.

• 339 model requests, 5 user prompts
• Total: 46.1 M effective tokens
• 16 requests (4.7 %) accounted for 23.9 M — 51.8 % of the entire window
• Per-request cost of a cache rebuild: ~1.9 M effective vs. ~80–100 k for a normal request

Over the full 5-hour window: 249.5 M raw cache_read and 17.6 M raw cache_write across
425 requests. Weighted, cache writes alone are 57 % of the window's cost.

At 21:50 the session then hit the 1 M context ceiling and had to auto-compact — i.e. the
most expensive requests were spent on a context that was discarded minutes later.

Expected behaviour

A cache entry written with a 1-hour TTL should survive at least the 33–61 seconds between
consecutive requests in the same session. A full-context re-write should not be triggered
silently and repeatedly.

Additional observations / possible contributing factors

1. Concurrent sessions. Four Claude Code sessions were active on this machine at the

same time, holding ~2.9 M tokens of cache in total (995 k + 780 k + 620 k + 540 k).
This looks like cache eviction under capacity pressure rather than TTL expiry — but from
the user's side it is indistinguishable, and the cost is charged either way.

1. No warning. Nothing in the UI indicates that a request cost 20× the normal amount,

or that a session's size has made every further step disproportionately expensive.

1. No back-pressure. The session was allowed to grow to 995 k tokens and keep issuing

requests until it hit the hard ceiling, each request re-writing ~950 k tokens.

Suggested fixes

• Do not silently re-write the full context; if the cache prefix is lost, surface it.
• Warn (or throttle) when a session's context passes a threshold where each step costs a

significant share of the usage window.

• Make cache eviction across concurrent local sessions predictable, or scope cache capacity

per session.

Reproduction

1. Run 3–4 Claude Code sessions concurrently on one machine.
2. Grow one session past ~900 k tokens of context (browser automation with screenshots gets

there quickly).

1. Watch cache_read_input_tokens in the session transcript: it collapses to the

system-prompt prefix every ~40 seconds while cache_creation_input_tokens jumps back to
the full context size.