[BUG] agentProgressSummaries fork leaves an already-cached large tool result outside its cache breakpoint

Summary

With agentProgressSummaries: true, we observed a progress-summary fork place its cache_control breakpoint before a large, unchanged tool result that the specialist's immediately preceding request had included in a cache write. The fork reuses the older prefix but processes the newest tool-result segment as uncached input.

The installed SDK declaration describes summaries as forking the subagent conversation approximately every 30 seconds using its model and prompt cache. In this file-heavy workload, summary calls had substantial uncached input despite excellent cache reuse on the specialist's own calls.

Environment

• @anthropic-ai/claude-agent-sdk 0.3.288; bundled Claude Code 2.1.288
• TypeScript SDK, Linux ARM64
• Amazon Bedrock Runtime, US cross-region inference profile us.anthropic.claude-fable-5-1 (not the Mantle endpoint)
• Foreground specialist started through the Agent tool
• Main session options include agentProgressSummaries: true
• Evidence: production Bedrock model-invocation records, including request bodies and returned token usage; no customer content is included below

Observed request pair

The specialist request and summary request are six seconds apart. Sizes below are UTF-8 byte lengths after JSON serialization; CC denotes an explicit cache_control breakpoint. Message indices are zero-based.

specialist request (11 messages)
  [8]  assistant: tool_use                       294 B
  [9]  user:      tool_result                 86,151 B
  [10] system:    text (CC) + text

  input_tokens:                32
  cache_creation_input_tokens: 43,620
  cache_read_input_tokens:     37,156

summary fork (11 messages)
  [8]  assistant: tool_use (CC)                  334 B
  [9]  user:      tool_result                 86,151 B
                  + summary instruction         562 B
  [10] system:    text

  input_tokens:                43,666
  cache_creation_input_tokens: 166
  cache_read_input_tokens:     37,156

The tool-result block is identical in both requests. The top-level system prompt and tool definitions are also identical. The summary instruction is an additional text block in the user message, not an edit inside the tool-result block.

The requests are not otherwise identical: the specialist's trailing system message contains two text blocks, including the cache breakpoint; the fork uses a string-valued trailing system message and omits the second instruction. The fork also adds fallback-credit-2026-06-01 to the beta list. These differences should be considered when fixing prefix reuse.

The specialist writes a 43,620-token segment, but the summary's cache read stops at the older 37,156-token prefix. Its breakpoint precedes the identical large tool result, leaving that result outside the cacheable prefix of the summary request. This is not explained by expiration: the requests are six seconds apart.

Measured scope

Across the observed specialist execution:

| Request category | Calls | Uncached input | Cache writes | Cache reads | Output |
|---|---:|---:|---:|---:|---:|
| Specialist work | 13 | 386 | 202,978 | 1,436,337 | 51,812 |
| Progress summaries | 10 | 177,636 | 39,583 | 1,282,371 | 187 |

At published Fable 5.1 list rates ($10 input, $12.50 5-minute cache writes, $0.25 cache reads, $50 output per million tokens), summaries cost approximately $2.60. This is 22.3% of the approximately $11.64 entire parent intake session, or 32.1% of the specialist-plus-summary portion. These are token-derived estimates, not reconciled billing charges.

Not every summary has the exact layout above. Some fork while a tool batch is still completing, before the specialist has submitted those results to the model; one forks after an assistant text response. We are not claiming every uncached summary token was previously cached or that every summary has a final tool_use breakpoint.

Reproduction guidance

This is an observed production request pair, not yet a standalone synthetic reproduction. To attempt reproduction without private data:

1. Enable agentProgressSummaries and delegate foreground work to a specialist.
2. Have it read a large generated text file, then continue working long enough for periodic summaries.
3. Capture specialist and summary requests with returned usage.
4. Compare a summary generated after a specialist request that included the same large tool result: inspect breakpoint placement, prefix identity, and uncached input.

Expected behavior

When the specialist has already cached a prefix containing the latest tool results, a subsequent summary should preserve and reuse that prefix where possible, placing summary-specific instructions after it. Prefix compatibility must include the trailing system messages and other relevant request settings; merely moving one breakpoint may not be sufficient.

Results that have not yet been submitted by the specialist may legitimately require new processing. The request is to avoid unnecessary uncached processing of an already-cached, unchanged prefix, not to guarantee zero-cost summaries.

Related prior work

• Claude Code v2.1.128 changelog records fixes for summary cache misses and repeated summaries on static transcripts. This observation is on 2.1.288.
• #56293 reports caching regressions associated with parallel teams and SendMessage; our observed pair instead concerns the summary breakpoint before a new tool result.
• Prompt caching documentation describes matching cached prefixes and explicit breakpoints.

We need user-visible progress summaries, so disabling them is not a suitable product workaround. This report is specifically about the observed cache-prefix reuse problem; broader summary cadence/model/context controls are a separate feature discussion.