[BUG] Async sub-agent completion can rebuild warm prompt cache, quickly burning usage limits in long-running sessions #64901

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

In long-running Claude Code sessions with a warm prompt cache, I observed cache collapses after async sub-agent completion notifications arrived after the parent assistant turn had already completed.

The observed failure mode matches the same "Mode B" pattern reported in broader cache invalidation issues:

• cache_read_input_tokens collapses to the system+tools floor
• cache_creation_input_tokens re-writes a large portion of the prior conversation history

What was observed:

• async/background task completion notifications can precede a cache collapse even while still inside the active cache TTL window
• the collapse can happen without ToolSearch
• the collapse can happen without large parallel tool bursts
• the collapse can happen with only 2 tool_uses in the triggering turn

Measured example from one session:

• cache_read_input_tokens: ~105.6k → ~23.5k
• cache_creation_input_tokens: ~1.9k → ~85.6k
• idle gap before the collapse: ~149s
• cache tier: forced 5m sliding window

In the same investigation:

• pure-idle cache survival was independently measured up to ~290s in other sessions
• several async/background events that arrived during active assistant turns did NOT produce a collapse
• synchronous sub-agent dispatches observed in prior sessions also did NOT produce a collapse

This suggests the issue may be tied specifically to how Claude Code resumes or injects async completion events after a turn has already closed, rather than to sub-agent execution itself.

This behavior makes async orchestration workflows difficult to use efficiently in long-running sessions because the cache can be partially re-created even when the session is still warm.

What Should Happen?

Async sub-agent completion notifications should preserve the warm message-history cache whenever possible.

If a background task finishes after the parent turn has already completed, the resumed request should ideally:

• preserve the previously cached conversation prefix
• reuse the existing message-history cache
• create cache entries only for the newly appended completion content

Cache reuse behavior should remain consistent regardless of whether the completion arrives:

• during an active assistant turn
• or after the parent turn has already ended

Error Messages/Logs

No explicit runtime error is displayed.

The issue is visible through Claude Code transcript inspection and cache accounting metrics.

Observed example:

before async completion:
* cache_read_input_tokens ≈ 105.6k

after async completion notification:
* cache_read_input_tokens ≈ 23.5k
* cache_creation_input_tokens ≈ 85.6k

The collapse occurred:

* inside the active cache TTL window
* without ToolSearch
* without a large parallel tool burst

Additional observations from the same broader investigation:

* queued user messages during assistant execution can correlate with the same cache collapse pattern
* attachments and PR-link injections can also correlate with the same pattern
* heavy parallel tool bursts can also correlate with the same pattern

The async-completion case reported here is narrower:
it isolates a collapse observed after a background completion resumed a previously finished turn.

Steps to Reproduce

1. Start a long Claude Code session and build a warm prompt cache.

2. Keep the cache HOT:

   • stay inside the active cache TTL window
   • avoid ToolSearch
   • avoid model switches
   • avoid heavy parallel tool bursts

3. Launch a background/async task or sub-agent.

4. Allow the parent assistant turn to fully complete.

5. Wait for the async/background completion notification to arrive after the turn has already ended.

6. Inspect the next assistant request in the session transcript JSONL.

Observed in my sessions:

• cache_read_input_tokens can collapse to the system+tools floor
• cache_creation_input_tokens can spike and re-create a large portion of the prior history

Control observations:

• some async/background completion events arriving during active assistant turns did not produce the same collapse
• earlier inline sub-agent dispatches observed in other sessions also did not produce the same collapse pattern

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Probably 2.1.152 (Claude Code). The behavior became much more noticeable in recent orchestration-heavy workflows, but I do not have a confirmed last-known-good version.

Claude Code Version

2.1.161 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

This report is intentionally narrower than the broader prompt-cache invalidation investigations already discussed in:

• Prompt cache fully re-created after turns with many parallel tool calls (cache_read collapses to system+tools floor) — ~74% of cache writes wasted on Opus 4.8 / v2.1.15x #63930

The goal here is to isolate one specific observed trigger:
async/background completion notifications arriving after a parent turn has already finished.

The broader investigation found several different patterns associated with cache collapses:

• heavy parallel tool bursts
• ToolSearch deferred-tool materialization
• queued user-message injection
• attachment / PR-link injection
• async/background completion notifications

The async/background case is notable because:

• the cache can still be warm
• no ToolSearch is required
• no large parallel burst is required
• the observed triggering turn can remain small

One possible explanation is that the async completion is being injected into conversation state through the same queue/injection path used by queued user messages or other mid-history insertions, which may perturb the cached message-history prefix.

However, that mechanism is only an inference from transcript behavior and cache metrics; I do not have visibility into Claude Code's internal cache breakpoint handling.

Possibly related to:

• Prompt cache fully re-created after turns with many parallel tool calls (cache_read collapses to system+tools floor) — ~74% of cache writes wasted on Opus 4.8 / v2.1.15x #63930 ("Prompt cache fully re-created after turns with many parallel tool calls")

The behavior reported here appears similar at the cache-metrics level ("Mode B" style collapse of message-history cache), but this report isolates a different observed trigger:
async/background completion notifications arriving after a parent turn has already completed.

In the sessions analyzed for this report, the observed collapse could occur:

• without ToolSearch
• without heavy parallel tool bursts
• while still inside the active cache TTL window