Prompt cache repeatedly dropped mid-session (17x in 3h), causing ~10.4M tokens of redundant cache writes

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?

Product: Claude Code CLI (macOS, Darwin 25.5.0)
Claude Code version: 2.1.220 (Claude Code)
Model: claude-fable-5
Session ID: f5ba2632-a8da-4a78-a5af-ac451683f84d
Session window: 2026-07-31 08:21:56Z to 11:29:36Z (05h21 to 08h29 America/Sao_Paulo)
Data source: the local Claude Code transcript on my machine (~/.claude/projects/.../f5ba2632-….jsonl), deduplicated by requestId. All figures below are read from message.usage as returned by the API.

---

Summary

During a single 3-hour session, the prompt cache was silently dropped 17 times. On each occurrence cache_read_input_tokens collapsed from ~640,000 to exactly 25,165, and the entire conversation (550,000 to 678,000 tokens) was re-written to cache.

Those 17 requests account for 10,410,754 tokens of cache creation — 93% of all cache creation in the session, and roughly 60% of the session's total cost.

The cache had been working correctly for the first 128 requests of the same session immediately beforehand.

---

Expected behaviour

With a stable prefix and a 1-hour TTL (cache_creation.ephemeral_1h_input_tokens), consecutive requests should read the cached prefix and write only the incremental delta. This is what the first hour of the session did (see below).

Observed behaviour

After 09:19:09Z, requests intermittently fell back to a 25,165-token prefix and re-wrote everything after it. The failures interleave with normal requests — the cache was not permanently lost, it kept dropping and recovering.

The fallback value is identical to the byte on all 17 occurrences (25,165), which suggests every breakpoint after the first was missed, not that the entry expired naturally.

---

Timeline

Normal behaviour, requests 0 to 127 (08:21:56Z to ~09:17Z):

| req # | time (UTC) | cache_read | cache_creation |
|---|---|---|---|
| 0 | 08:21:56 | 21,000 | 43,000 |
| 25 | 08:28:41 | 197,000 | 8,000 |
| 50 | 08:40:30 | 355,000 | 1,000 |
| 75 | 08:51:54 | 450,000 | 3,000 |
| 100 | 09:05:04 | 523,000 | 5,000 |
| 125 | 09:17:25 | 641,000 | 3,000 |

Then, from request 128 onward, the 17 failures:

| # | timestamp (UTC) | request_id | cache_read | cache_creation |
|---|---|---|---|---|
| 1 | 2026-07-31T09:19:09Z | req_011CdZtKQ8HjeGR3Vej1QWHN | 25,165 | 549,529 |
| 2 | 2026-07-31T09:19:58Z | req_011CdZtNiSCjNF6RQ6Ef3GeD | 25,165 | 553,394 |
| 3 | 2026-07-31T09:20:49Z | req_011CdZtTUF4kHCxyymmWU1eK | 25,165 | 557,108 |
| 4 | 2026-07-31T09:21:16Z | req_011CdZtW1s8vp6aZJg3NJZVo | 25,165 | 561,488 |
| 5 | 2026-07-31T09:22:09Z | req_011CdZtYTz56th8yC84dLSZD | 25,165 | 565,500 |
| 6 | 2026-07-31T09:39:30Z | req_011CdZutVFu1jrH8dTRdbmeC | 25,165 | 603,342 |
| 7 | 2026-07-31T09:39:52Z | req_011CdZuva7uDnC9oqdy8VVF7 | 25,165 | 604,334 |
| 8 | 2026-07-31T09:43:19Z | req_011CdZvBSEo8V6KMDFRvvYSe | 25,165 | 608,177 |
| 9 | 2026-07-31T10:00:18Z | req_011CdZwUjXhfCVCb4t9wtehe | 25,165 | 629,081 |
| 10 | 2026-07-31T10:00:38Z | req_011CdZwWYNY3LXTfVPnLuWrC | 25,165 | 629,253 |
| 11 | 2026-07-31T10:11:26Z | req_011CdZxK49Dasba8VQhsiF1L | 25,165 | 644,343 |
| 12 | 2026-07-31T10:13:02Z | req_011CdZxSu9hjivNVKbZV9ePK | 25,165 | 643,885 |
| 13 | 2026-07-31T10:13:42Z | req_011CdZxV7ZdY8DQLQxaBMJuu | 25,165 | 649,294 |
| 14 | 2026-07-31T10:15:08Z | req_011CdZxaR3yxs3LAy4dFduUs | 25,165 | 643,375 |
| 15 | 2026-07-31T10:16:31Z | req_011CdZxeuqxUA8UCamTgscBL | 25,165 | 640,527 |
| 16 | 2026-07-31T10:26:49Z | req_011CdZyVUwNNFoW7dYcjBiHi | 25,165 | 650,285 |
| 17 | 2026-07-31T11:24:52Z | req_011Cda3w4JjB28rtgpBvi9bv | 25,165 | 677,839 |

Note requests 9 and 10 are 20 seconds apart, and 6 and 7 are 22 seconds apart. In both pairs the second request also fell back to 25,165 — so this is not TTL expiry.

Session totals (241 requests): cache_creation 11,173,921, cache_read 111,128,632.

---

Controlled comparison

To rule out my own usage pattern, I compared this against every other session in the same project on the same model (claude-fable-5) from 2026-07-20 onward. 17 sessions total.

| session start | duration | reqs | cost/req (US$ eq.) | images in context | peak context | full re-caches |
|---|---|---|---|---|---|---|
| 31/07 05h21 | 3h08 | 241 | 1.44 | 185 | 709k | 17 |
| 27/07 07h49 | 6h38 | 389 | 0.64 | 70 | 903k | 0 |
| 24/07 09h51 | 14h56 | 1095 | 0.63 | 90 | 980k | 1 |
| 26/07 11h18 | 11h29 | 719 | 0.58 | 4 | 961k | 0 |
| 25/07 12h02 | 2h20 | 178 | 0.39 | 7 | 601k | 1 |
| 30/07 12h33 | 9h03 | 404 | 0.69 | 177 | 995k | 1 |
| 23/07 13h04 | 7h37 | 496 | 0.65 | 45 | 977k | 0 |
| 29/07 14h48 | 9h58 | 646 | 0.55 | 123 | 999k | 2 |
| 21/07 17h23 | 4h46 | 291 | 0.53 | 22 | 730k | 0 |
| 28/07 17h44 | 2h07 | 114 | 0.47 | 27 | 470k | 0 |
| 20/07 20h49 | 2h23 | 197 | 0.33 | 38 | 450k | 0 |
| 28/07 22h52 | 1h21 | 122 | 0.29 | 52 | 323k | 0 |

(five further sessions omitted for brevity; all in the 0.29–0.65 range with 0–1 re-caches)

The affected session is the only outlier, at more than double the cost per request of the worst of the other sixteen.

The obvious candidate explanations are each contradicted by a session in this table:

• Not image volume. 30/07 had 177 images against this session's 185, and had 1 re-cache.
• Not context size. 30/07, 29/07, 24/07 and 26/07 all reached 961k–999k, larger than this session's 709k peak, without the problem.
• Not how fast context grew. 28/07 (4.1k/req) and 25/07 (3.4k/req) filled faster than this session (2.9k/req) and passed clean.
• Not TTL expiry. Requests 20 seconds apart both fell back (see above).

The only attribute unique to the affected session is its start time of 05h21 America/Sao_Paulo (08h21 UTC). Every other session in the set starts at 07h49 local or later. I want to be clear that this is a single observation and I am not claiming causation — I am reporting it because it is the only variable I could not eliminate.

---

Impact

The 17 redundant re-caches consumed 10,410,754 tokens of cache-write billing that should have been cache reads. At claude-fable-5 input pricing with a 1-hour TTL write multiplier, that is roughly US$208 of a US$348 session.

On a subscription plan this surfaced as approximately 25% of my weekly allowance consumed in 3 hours, against a normal full working day (07h to 22h) of around 10%. That effectively cost me two working days.

---

Questions

1. Is there a known condition under which a cached prefix is dropped server-side while later requests still hit the first breakpoint at a fixed offset?
2. The fallback value was byte-identical (25,165) on all 17 occurrences. Does that indicate breakpoint invalidation rather than eviction?
3. Is there anything a client can do to detect this at runtime and avoid re-writing a 650k-token prefix?

I can provide additional token-accounting data from the transcript on request. I will not attach the raw session transcript to a public thread, as it contains the full contents of my work. If you need it, please request it through a private support channel and I will send it there. Billing is being handled separately through support.

---

Update (2026-08-02)

The anomaly has not recurred. Since this incident I have run 12+ sessions on the same Claude Code version (2.1.220) and the same model, including a 133-request session on 2026-08-02 with a ~780k-token context, all with healthy cache behaviour (incremental writes of 1-4k tokens per request, no collapse of cache_read_input_tokens). This appears to have been a single-day, session-specific event on 2026-07-31. The only variable I could not eliminate: it was the only session of the month started before 07:49 local time (05:21).

Possibly relevant correlation (recalled by me on 2026-08-02): around 05:00 local time that same morning, shortly BEFORE this session started (05:21), Claude Code displayed a red error banner saying a version auto-update had FAILED and suggesting I run doctor. The installed version did not change (2.1.220 before, during and after, per the version field in the transcripts). The cache anomaly began at 06:19 in the first session started after that failed update, and never recurred in any later session. A client left in a partially-updated or inconsistent state by the failed updater seems like a plausible trigger worth investigating.

---

Possibly related issues

• #63930 — cache_read collapsing to the system+tools floor with full cache re-creation (same drop signature; in our case it recurred 17x mid-session on v2.1.220 and correlates in time with a failed auto-update earlier that morning)
• #81234 — weekly quota draining faster than transcript-accounted load suggests (similar meter-side symptom observed on this account since 2026-07-31)

What Should Happen?

The prompt cache should persist across consecutive requests in the same session: cache_read_input_tokens should keep growing with the conversation (~640k in this session), with only small incremental cache writes (0-8k tokens per request), exactly as it did for the first 128 requests of this same session. A full re-write of the entire conversation (550k-678k tokens) should only happen on a genuine cache expiry - not 17 times mid-session, sometimes 20 seconds apart.

Error Messages/Logs

No error messages during the session itself - the cache drops are completely silent (requests succeed normally; the only trace is in the transcript's message.usage fields, detailed in the description).

The one visible error that morning was Claude Code's auto-update failure banner ("update failed", prompting to run the doctor), shown at ~05:00 local time, minutes before the affected session started at 05:21. The anomaly has not recurred since the client was restarted.

Steps to Reproduce

1. macOS (Darwin 25.5.0), Claude Code 2.1.220, model claude-fable-5, long interactive session with a large context (this session reached 550k-678k tokens).
2. Suspected trigger: minutes before the session started, Claude Code's auto-update FAILED (red "update failed, run doctor" banner at ~05:00 local time). The session was started at 05:21 without restarting or repairing the client. The anomaly began at 06:19, and it has never occurred again since the client was restarted.
3. Use the session normally (regular messages and tool calls) as the conversation grows past ~500k tokens.
4. To observe: read the session transcript at ~/.claude/projects/<project>/<session-id>.jsonl, deduplicate records by requestId, and inspect message.usage per request.
5. Bug signature: cache_read_input_tokens collapses from ~640,000 to exactly 25,165 (the system+tools floor, byte-identical across all 17 occurrences) while cache_creation_input_tokens jumps to the full conversation size (550k-678k). This happened 17 times in 3 hours, interleaved with normal requests, twice only ~20 seconds apart (which rules out normal TTL expiry).

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Session ID: f5ba2632-a8da-4a78-a5af-ac451683f84d (2026-07-31, 08:21-11:29 UTC). Request IDs for all 17 affected requests are preserved and available on request.
• Hypotheses tested and eliminated against 16 other sessions from the same month (details in the description): image volume, context size, context growth rate, TTL expiry (two drops were ~20 seconds apart), and version regression (12 clean sessions on the same 2.1.220 since Jul 25).
• Cost impact: the 17 re-writes account for ~10.4M cache-creation tokens. Cost per request in this session was ~3-5x the normal range of the 16 comparison sessions.
• Possibly related meter-side symptom on this account since Jul 31: the weekly-limit meter appears to move ~2.5-3x faster per unit of transcript-accounted usage than before that date (see #81234).
• Support ticket for this case (with full account details and data): 215475315446737.
• Happy to share the full deduplicated per-request usage data extracted from the transcript.