[BUG] Waking a parked subagent re-caches its entire context: only the system prefix is served from cache, even minutes later within TTL

Summary

When a stopped/parked subagent is woken (by SendMessage from its parent, or by a background-task completion notification), the next API request serves only the ~6K-token system prefix from cache and re-writes the entire remaining conversation at cache-write rates. This happens even when the wake arrives minutes after the subagent's last turn, well inside the cache TTL, so it is not cache expiry: the conversation-level cache breakpoints appear to be discarded when the subagent's request is reassembled on wake.

Environment

• Claude Code 2.1.233, macOS (darwin 24.6.0)
• Session with 1-hour prompt-cache TTL
• Multi-agent orchestration: a parent session spawning claude-type background subagents that park between turns (waiting on child agents / background test runs) and are woken by SendMessage or task notifications

Evidence (from session transcripts, usage deduped by message id)

One subagent's wake sequence, all within a single 1h-TTL session. Every wake shows cache_read_input_tokens pinned at exactly the system-prefix size while the whole conversation is re-written:

| wake (UTC) | gap since last turn | cache_read | cache_creation |
|---|---|---|---|
| 20:35:37 | 11m | 6,007 | 82,903 |
| 20:39:10 | 2m | 6,007 | 97,752 |
| 20:43:06 | <1m | 6,007 | 128,121 |
| 20:51:54 | 5m | 6,007 | 150,735 |
| 21:03:19 | 11m | 6,007 | 152,653 |
| 21:21:26 | 18m | 6,007 | 153,767 |

The same signature appears in every parked subagent of the session: 12 subagents, 54 full-context rewrites, 5.2M tokens re-cached at write rates in a 2-hour run. During a subagent's normal working turns, incremental caching behaves correctly (large cache reads, small writes); the full rewrite happens only on the first request after a wake.

Note the 2-minute and sub-minute gaps: no TTL explains those. The cache_read value being exactly the system-prefix size every time suggests the wake path rebuilds the request with a cache breakpoint after the system prompt but without the breakpoints that covered the accumulated conversation.

Repro outline

1. Spawn a background subagent (claude type) that does some work (grow its context to ~100K), then stops its turn to wait (e.g. on a background task).
2. A few minutes later, SendMessage it from the parent.
3. Compare the woken request's usage against the subagent's prior turns: prior turns show cache_read ≈ full context; the wake shows cache_read ≈ system prefix only and cache_creation ≈ full context.

Expected

A wake within the TTL should be an append: cache_read ≈ the full prior context, cache_creation ≈ the injected message plus normal growth.

Impact

In orchestration patterns where subagents park between phases (parent pings, task-completion wakes), this multiplies input spend: in the measured session the rewrites alone were roughly a quarter of total weighted token cost. It also penalizes exactly the workflows the docs encourage (backgrounded long runs, parent/child messaging).

Related, but distinct

• #74318 measures subagent cache-TTL strategy (5m vs 1h trade-offs). This report is orthogonal: within any TTL, the wake path discards conversation breakpoints entirely.
• #81389 asks for parent-cache inheritance at spawn. This is about a single subagent's own cache across its own turns.