Resuming completed subagents replays the full transcript per message — burned 75% of a weekly limit in one afternoon
Status Open
Maintainer reply None cached
Activity 3 comments · opened Aug 16, 2026
What happened
During a long orchestration session, the assistant repeatedly used SendMessage to resume previously completed background subagents (spawned via the Agent tool) to hand them follow-up tasks and small mid-flight corrections ("addenda").
Each resume replays the agent's entire prior transcript into the resumed session. The agents in question had transcripts of ~650K–960K tokens (large greenfield build tasks), and they were resumed 6–8 times each. Every small addendum therefore re-billed the whole growing history. Net effect: ~75% of the account's weekly usage limit consumed in a single afternoon, with most of it being transcript replay rather than new work.
Why it's easy to fall into
- The
SendMessage/resume affordance looks cheap — "send the agent one more instruction" — and nothing at the call site indicates that the cost is proportional to the agent's full history, not to the message. - Resuming feels like the natural way to keep context ("the agent already knows the repo"), when in practice a fresh agent with a self-contained brief pointing at files on disk is dramatically cheaper and works as well.
Suggestions (any one of these would have prevented it)
- Surface the cost at the call site: the resume result (or a pre-flight warning) could state "resuming this agent will replay ~N tokens of prior transcript."
- Incremental resume: prompt-cache or otherwise avoid re-billing the unchanged transcript prefix on each consecutive resume of the same agent.
- Docs/system-prompt guidance for the orchestration pattern: prefer fresh agents with batched, self-contained briefs; treat resume as expensive and exceptional; never drip-feed addenda.
Environment
- Session id:
d78d1e9b-c15d-4ba8-ac16-919dc5d23cbe - Model:
claude-fable-5(Claude Code CLI, macOS/darwin 25.0.0) - Subagent type:
general-purpose, resumed viaSendMessagewith the spawn-returned agent id - Subagent transcript sizes at time of resumes: ~650K–960K tokens each; 6–8 resumes per agent
Filed at the user's request; happy to provide more detail from the session.
3 Comments
Related corpus data, with an important scope caveat: this analysis captures text-bearing wake/resume boundaries after a completed assistant turn, including task notifications. It is broader than explicit
SendMessage-only resumes, so it measures an adjacent cache-cost pattern rather than the exact operation reported here.In a fixed 2026-08-28 snapshot of my local Claude Code history containing 9,785 subagent transcripts, I found 4,879 boundaries, of which 4,853 had valid cache-share metrics. Repeated assistant content-block records were deduplicated per transcript by
requestId. Definingcached_share = cache_read / (input + cache_read + cache_creation)on the first post-boundary request, with "warm" ascached_share >= 0.85and "cold" as< 0.65:input_tokens + cache_creation_input_tokens, n=3,337Excluding the drill-heavy current session changes those figures only slightly (49.60% / 3.53% / 226,802). The post-2.1.243 slice is smaller and better under five minutes: 66.13% warm (n=186; 62.50%, n=152, excluding the drill session), with the remaining ~34% below the 0.65 cold threshold (the warm share is identical at both thresholds in this slice, so nothing sits in between); the >=5-minute result is 1.39% warm (n=72). Separately, all 8,127 observed 2.1.243+ subagent assistant requests attributed cache creation to the five-minute tier and zero to the one-hour tier.
So the narrower conclusion I think this broader population supports: cache reuse is still frequently poor inside the nominal five-minute window (roughly one-third cold even on 2.1.243+), and cold boundaries carry a very large uncached first request. These data do not establish that explicit
SendMessageresumes replay the complete transcript.The corpus does not identify the clock origin. One hypothesis is that the TTL begins when the earlier cache entry is created, at or near request processing, rather than when its response completes; that would need a controlled timing experiment.
These figures were independently reproduced by a second clean-room implementation from the same definitions. Happy to share the method.
resuming a completed subagent replays its whole transcript per ping — the cost scales with history, not message size.
fresh agent with a self-contained brief pointing at files on disk beats "send one more instruction" on a 900k-token history every time.
resuming a completed subagent replays its whole transcript per ping — the cost scales with history, not message size.
fresh agent with a self-contained brief pointing at files on disk beats sending one more instruction on a huge history.