[BUG] Fable 5.1 subagents re-cache their entire context (200-430K tokens) turn after turn: the 5-minute subagent TTL expires inside Fable 5.1's long turns. 8 parallel agents re-wrote 2.9M tokens in 40 min; 0 such rewrites on Opus 5 / Fable 5 subagents in the same week

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related but different: #84289, #87215, #89621, #91289)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.260 now; the data below is from 2.1.258)

What's Wrong?

Background subagents spawned with the Agent tool on Claude Fable 5.1 keep losing their whole conversation cache mid-run. On the affected turns cache_read_input_tokens is pinned at exactly the shared system prefix (33,578 tokens) and cache_creation_input_tokens is the entire conversation again (213K-432K), on the 5-minute bucket (usage.cache_creation.ephemeral_5m_input_tokens). The main session, on the 1-hour bucket, does not show this in the same runs.

The pattern is consistent with the documented 5m TTL for subagents (#84289) being too short for Fable 5.1: a single Fable 5.1 turn (thinking + tool calls) routinely takes 5-10 minutes, so by the next request the 5m entry is gone and the full context is written again at cache-write rates. Whatever the exact mechanism, the effect is that every long subagent turn costs a full re-cache.

Numbers from one session (2026-09-03, 15:24-16:21 UTC, Claude Code 2.1.258, Max 20x subscription, macOS): a parent session launched 8 research subagents in parallel (WebSearch/WebFetch/Write heavy). Usage deduped by message.id, every entry from ~/.claude/projects/**/agent-*.jsonl:

| time (UTC) | agent | call # | cache_creation | cache_read | TTL bucket | gap since previous response |
|---|---|---|---|---|---|---|
| 15:41:02 | a3ab40ae | 8 | 213,484 | 0 | 5m | 3.5 min |
| 15:57:58 | a9cd220c | 9 | 212,879 | 33,578 | 5m | 1.5 min |
| 16:03:25 | a629058a | 14 | 431,885 | 33,578 | 5m | 5.7 min |
| 16:04:47 | a96ab1d3 | 8 | 270,587 | 33,578 | 5m | 6.0 min |
| 16:08:31 | a9a4add8 | 10 | 271,077 | 33,578 | 5m | 8.8 min |
| 16:09:27 | ad6e8ac3 | 10 | 263,804 | 33,578 | 5m | 5.2 min |
| 16:10:29 | a96ab1d3 | 9 | 298,254 | 33,578 | 5m | 5.7 min |
| 16:13:56 | a9cd220c | 13 | 303,392 | 33,578 | 5m | 10.1 min |
| 16:15:45 | ad6e8ac3 | 11 | 300,061 | 33,578 | 5m | 6.3 min |
| 16:16:19 | a9a4add8 | 12 | 319,053 | 33,578 | 5m | 7.2 min |

10 full-context rewrites = 2.88M cache-write tokens in under 40 minutes, across 6 of the 8 agents; several agents did it twice in a row (a96ab1d3 at 16:04 and 16:10, ad6e8ac3 at 16:09 and 16:15, a9a4add8 at 16:08 and 16:16). The request right after each rewrite reads the full context again (e.g. 304,655 read / 1,595 written at 16:09:08), so the cache itself works; it just does not survive a Fable 5.1 turn. At API list price ($12.50/MTok cache write) that is ~$36 of re-caching in one 40-minute session, on a plan where it shows up as the 5-hour window disappearing.

Same-week comparison, all subagent transcripts on this machine (Aug 25 - Sep 4):

| subagent model | agent files | API calls | cache_creation total | full-context rewrites (>150K written, <50K read, not the first call) |
|---|---|---|---|---|
| claude-fable-5 | 13 | 179 | 1.43M | 0 |
| claude-opus-5 | 58 | 1,720 | 6.80M | 0 |
| claude-fable-5-1 | 24 | 314 | 8.43M | 10 (2.88M tokens) |

Fable 5.1 subagents made 18% of the subagent calls and 50% of the subagent cache writes.

What Should Happen?

A subagent's cache should survive its own turns. Either subagents on a subscription should get the 1-hour TTL like the main conversation (the docs in #84289 say they get 5m; transcripts there say 1h; here they clearly get 5m), or the harness should keep the 5m entry alive during long turns (a keep-alive or a refresh before the tool phase), or at minimum Fable 5.1 subagents should be exempt from the 5m bucket since their turns routinely exceed it.

Error Messages/Logs

No errors. The signal is only in usage: cache_read_input_tokens equal to the system-prefix size and cache_creation.ephemeral_5m_input_tokens equal to the rest of the context, on non-first requests of a subagent.

Per-request requestIds for the table above: req_011Cegkz4G6pcp4BEBcMx6rf, req_011CegnDk6hur3TpBiVRvN4q, req_011CegngQGcCaZWFDeX27bDL, req_011CegnitdUmztSGZ4bGCB8D, req_011Cego5JuHbpDSJMVwt2Asm, req_011Cego3ZRc6wkH66oMVNNoP, req_011CegoBhEso5yJELccfnF52, req_011CegoUp38R6HcmFZNVDyxf, req_011CegodGZ3FfZ9eJ6APREGg, req_011Cegog36FiqUspbW2DW9N8.

Steps to Reproduce

1. Main session on claude-fable-5-1, subscription plan (Max), Claude Code 2.1.258 (also seen on 2.1.255).
2. Launch 6-8 general-purpose subagents in parallel with run_in_background: true, each doing web research (WebSearch + WebFetch) and writing multi-page reports, so each turn thinks for minutes and the context grows past ~200K.
3. After ~15 minutes, look at each agent-*.jsonl: cache_read_input_tokens collapses to the system-prefix size and cache_creation.ephemeral_5m_input_tokens equals the whole context, on turns 8-14.
4. Same workload with claude-opus-5 or claude-fable-5 subagents: no such rewrites.

Claude Model

claude-fable-5-1 (main session and subagents)

Is this a regression?

Yes. Zero full-context subagent rewrites on Fable 5 and Opus 5 subagents in the same week, same machine, same kind of workload.

Last Working Version

Fable 5 subagents on 2.1.246/2.1.247 (Aug 27-Sep 1) did not show it. Cannot separate model from harness version since Fable 5.1 only exists from 2.1.255.

Claude Code Version

2.1.258 (data); 2.1.260 installed now, not yet re-measured

Platform

macOS

Operating System

macOS 26 (Darwin 25.6.0)

Terminal/Shell

Claude desktop app (Code tab) and zsh terminal

Additional Information

• Related: #84289 (docs vs reality on subagent TTL), #87215 (parked subagent wake re-caches everything, 2.1.233), #89621 (large multimodal subagent full re-cache, 2.1.245), #91289 (Fable 5.1 burning limits). This report adds the Fable 5.1 angle: the TTL bucket is 5m on every affected request and the rewrites line up with turns longer than 5 minutes.
• I also see the main session (1h bucket) re-cache its entire context inside the TTL in two situations, which look like a different bug: 873,744 tokens written / 45,505 read 18 seconds after the previous response, on the turn that consumed a <task-notification> from a background subagent (2026-09-03 22:11:26 UTC, req_011CehGk3ov2ATENzdwaWnGw); and 885,344 written / 39,156 read one minute after the previous response, on a user turn that carried file attachments (2026-09-03 14:43:21 UTC, req_011CeggXRzbDXtGpyPbj2V74). Happy to open a separate issue for those if useful.
• Raw per-request usage (JSON) available on request.