Subagents use the 5-minute prompt cache while the main session uses 1-hour; slow responses cause repeated full-context cache rewrites

Environment: Claude Code 2.1.278, Claude desktop app (Code tab), macOS, model claude-opus-5-5.

What happened

A session spawned 16 background subagents (Agent tool, general-purpose) to read a local corpus and view images. Within ~65 minutes the account hit its session limit and every Claude Code session stopped.

Token totals taken from the usage fields in the session transcripts:

| | Main session | 16 subagents |
|---|---|---|
| API calls | 55 | 419 |
| Cache-write tokens | 0.22M | 19.65M |
| Cache-read tokens | 7.8M | 74.1M |
| Output tokens | 0.05M | 0.71M |

The gap

• Every subagent cache write was ephemeral_5m_input_tokens (19.65M, 0 in the 1-hour class). Every main-session cache write was ephemeral_1h_input_tokens. The main session's system prompt states the session uses a 1-hour cache TTL; subagents did not get it.
• 44 subagent calls were full cache misses: 220–435K tokens written with only the ~32K shared prefix read. Those calls account for roughly 15M of the 19.65M cache-write tokens.
• 35 of the 44 misses came more than 300 seconds after the previous response in that agent (median gap 439s, max 1,557s). Cache hits had a median gap of 36s.
• The agents were not idle in those gaps — tool calls between requests took seconds. The time was spent waiting on the API response. Two agents were also killed by the watchdog with "Agent stalled: no progress for 600s".

So when responses to large-context subagents take longer than five minutes, the cache expires while the agent is waiting, and the next call re-bills the whole context at the write rate. Larger contexts make responses slower, which makes this more likely, which makes each miss more expensive.

Expected

Subagents get the same cache TTL as the session that spawned them (1 hour here), or the cache is kept warm while a subagent request is in flight.

Also worth considering

• Nothing warned that 16 concurrent subagents were each above 300K context, or that usage was accelerating, before the hard stop.
• The stop also killed nine subagents mid-task with no chance to save work.

Caveat

My own prompt design made this worse (too many agents, too much per agent), and I'm not claiming the cache behaviour is the only cause. By my estimate the misses were roughly half the price-weighted cost of the run.

I can share per-call usage rows (timestamps, cache_creation breakdown, gaps) on request.