Prompt cache misses beyond ~16K prefix in long-running subagent with large multimodal context — full ~550K cache_creation every request

Summary

A background subagent (Agent tool) with a large multimodal context (~500-614K tokens, mostly browser-extension MCP screenshots) stopped getting prompt-cache hits beyond the ~16K system prefix. Every subsequent request re-wrote the ENTIRE conversation to the 5m cache — ~500-600K cache_creation_input_tokens per request, on requests seconds apart with an unchanged history. One subagent consumed ~37.4M cache-write tokens in an afternoon, a large fraction of a Max plan's weekly usage.

Environment

• Claude Code 2.1.245, macOS (darwin 24.6.0)
• Model: claude-opus-5 (session and subagent)
• Subagent spawned via the Agent tool (general-purpose), long-running (~3.5h, 621 API requests), heavy use of chrome-extension MCP browser tools (screenshots inline in transcript)

Evidence (from the subagent transcript's usage records, deduped by requestId)

• 621 unique requests: cache_read 215,131,957 / cache_creation 37,454,546 (all ephemeral_5m, zero ephemeral_1h)
• 65 requests each wrote >400K (total 35.6M). All 65 of those read <20K from cache — i.e., only the system-prefix block hit; the conversation body missed entirely.
• The misses are NOT TTL expiry: consecutive full-rebuild requests are 15-90 seconds apart. Sample:

| timestamp (UTC) | cache_creation | cache_read | requestId |
|---|---|---|---|
| 16:33:47 | 520,298 | 0 | req_011CePnhqAHBB54rqykXTYAi |
| 16:35:01 | 506,926 | 16,269 | req_011CePnnFyPDp2R8gY2FX6A8 |
| 16:41:31 | 548,586 | 16,269 | req_011CePoJN9JP9zB1rZGemQ8E |
| 17:04:58 | 596,991 | 0 | req_011CePq5Z3WZKGXtdnKDx2aM |
| 17:11:32 | 600,067 | 0 | req_011CePqaJr3JPx67cnrjYkKf |
| 17:14:54 | 509,333 | 16,269 | req_011CePqrea9M2vbLx6jDZuDJ |

• From ~17:14Z onward nearly every request in an active 45-minute burst (turns ~20s apart) full-wrote ~510-590K with cache_read ≈ 0-16K.
• Earlier in the same subagent's life (context <300K) caching behaved normally — reads ≈ context, writes ≈ increment.

Expected

Requests seconds apart with an identical growing prefix should read the prior context from cache and write only the delta. Expected write volume for this workload ≈ final context size (~1M total); observed 37.4M.

Possible angles

• Cache breakpoint placement in large/multimodal conversations (only the ~16K tools/system block appears to stay cacheable once the conversation body is large)
• The date (2026-08-25) spans a context past 200K — if the harness switches request shape (e.g. long-context tier) mid-conversation, that might invalidate prefix identity
• Same requestId's usage is also logged 2-3x in the transcript JSONL (streaming re-records) — cosmetic, but it inflates any client-side accounting done from transcripts

Happy to provide the full requestId list or the transcript's usage records (sanitized) on request.