Claude Code's subagent status summaries can eat a fifth of a session's tokens, and there is no switch for them

When Claude Code runs a subagent, the agents panel shows a few words about what that subagent is doing. Users who have measured it say those few words are expensive. To produce them, Claude Code periodically forks the subagent's whole conversation, sends it to the same model the subagent runs on and asks for a three-to-five-word description. Several independent measurements put this agent_summary request at roughly 16 to 26% of a session's tokens or estimated spend, and Claude Code has no documented way to turn it off.

The numbers are public now because a gist from Flamerix AI reached the Hacker News front page early on October 29 under the headline "Claude Code burns ~15–20% of your tokens on a 3-word status line". The complaint itself is older. A GitHub issue asking for a supported off switch has been open since August 15, and it collects several sets of measurements:

• the original report, on version 2.1.233: one four-hour session with 27 subagents, in which 339 of 1,496 requests were agent_summary calls. That was 22.7% of all requests and, weighted at Opus 5 list rates, 18.0% of token cost. Together those calls produced 21,966 output tokens, about 65 per call;
• a September report on 2.1.276: a 1 hour 45 minute session with four custom subagents, in which summaries took 26% of cache-read tokens, at about 20 output tokens per call, firing every 30.8 to 31.3 seconds while an agent ran;
• Flamerix's own week of OpenTelemetry data: agent_summary was 16.4% of Claude Code's estimated spend, more than the main conversation's 15.7%, and 19.7% of requests, 96% of them on Opus, at about 9,000 input tokens per output token.

Why it costs so much

The mechanism follows from how the request is built. The original report quotes the call from the 2.1.233 bundle: it forks the subagent's context, allows one turn, denies every tool and is excluded from the transcript. The summary never goes back into the agent's context. Nothing the agent does depends on it.

But each call carries the subagent's full history. Most of it is served from the prompt cache, which is why skeptics in the Hacker News thread asked whether it matters. Cache reads are billed at a tenth of the normal input rate, but they still count, and they are paid again on every tick. The September reporter, whose longest subagent reached about 380,000 tokens of context, put it plainly: "the cost per tick is the agent's current context size." The bill therefore grows with how many subagents are running, how big their contexts get and how long they run. It has little to do with how much useful work they do. Three long-running subagents mean six summary calls a minute.

On a subscription the cost isn't a bill. It comes out of the usage limits. That makes the timing awkward. On October 28 Anthropic's Boris Cherny said the team had found no regression behind complaints of fast-draining Claude Code limits and pointed to heavy features such as Agent Teams and Workflows, adding that subagents inherit the parent's effort level. None of the public material we found says whether the "smaller things" his team is fixing include this request.

What Anthropic has and hasn't said

The feature isn't secret. The Claude Code changelog has fixed it before: version 2.1.128 fixed "sub-agent progress summaries missing the prompt cache (~3× cache_creation reduction)" and stopped summaries "firing repeatedly while a sub-agent's transcript is static", which capped the cost of idle subagents. Version 2.1.274 fixed a summary "being replaced by a runaway multi-paragraph reply."

What's missing is a control. The costs page of the Claude Code docs lists background token use, including conversation summarization for --resume, prompt suggestions and goal check-ins. The last two come with documented ways to turn them off. Subagent progress summaries aren't on that list. The environment variable reference doesn't mention them either, even under CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. In the issue, one user found an undocumented CLAUDE_CODE_AGENT_PROGRESS_SUMMARIES variable in the 2.1.300 bundle, and another reported that an older CLAUDE_CODE_ENABLE_NARRATION=0 stopped working after version 2.1.241. As of this morning the issue has six comments, all from users, and none from Anthropic staff.

The workaround, and its limits

Flamerix's fix doesn't modify Claude Code. It is an MIT-licensed, roughly 80-line Bun preload script, loaded through BUN_OPTIONS, that wraps setTimeout and setInterval and refuses to arm any timer whose callback source contains the summarizer's log line or the agent_summary id. In Flamerix's test runs on versions 2.1.301 through 2.1.312, a two-and-a-half-minute subagent run produced five summary forks without the hook and none with it. The visible cost is that the panel's per-agent status stops updating.

The authors are upfront about how fragile this is. It matches by source text, so a renamed log line or a refactored timer would bring the summaries back silently. It has only been tested on Linux; macOS and Windows are untested. It also has to reach the Claude Code daemon and every background process, not just the terminal you started from. It is a hack against the internals of a closed binary, and it should be treated as one.

The measurements also need context. They come from users and from Flamerix, whose own telemetry product, DRIM, flagged the anomaly, not from Anthropic. They come from subagent-heavy sessions, and the cost figures are Claude Code's own per-request estimates, not invoices. One Hacker News commenter who tested it found the effect real but smaller in their own sessions, "~8% at most", and said workflows did not seem affected. Someone who mostly runs a single session without subagents probably pays little for this.

The pattern is still worth noticing. A cosmetic UI feature runs on the most expensive model in the session, scales with context size and can't be turned off. Its cost only shows up for people who export OpenTelemetry data or capture raw request bodies, because the calls are excluded from the transcript. Until there's a setting, the measurements people collected themselves are the only way to see it.