Flamerix AI’s October 29, 2026, Claude Code analysis reports that automatic background-agent summaries consumed 16.4% of one team’s estimated weekly spend. That exceeded the 15.7% attributed to its main conversation.
Anthropic’s response puts the result in a different context. Claude Code team member edwinarbus said on Hacker News that the feature accounted for about 2% of cost across telemetry-sharing users, rising to about 6% for terminal usage. He described Flamerix’s deployment as unusually heavy on background agents.
The practical issue is measurable overhead: a feature that generates a few words of interface text can involve substantial model input. The two accounts describe different workloads, so neither percentage should become a universal estimate for Claude Code users.
What Flamerix Measured
Flamerix identified the requests through Claude Code’s OpenTelemetry export, grouping claude_code.api_request events by query_source. The relevant category was agent_summary.
Its published results describe one measured week:
| Metric | Flamerix’s reported result |
|---|---|
| Share of estimated Claude Code spend | 16.4% |
| Share of API requests | 19.7% |
| Main conversation’s share of estimated spend | 15.7% |
| Portion of summary spend attributed to Opus | 96% |
| Summary input tokens per output token | Approximately 9,000:1 |
“Spend” needs particular care here. Flamerix used Claude Code’s per-request cost_usd estimate, not an invoice. The gist says subscription users should understand the impact as consumption of rate-limit headroom, rather than a matching increase in their subscription bill.
That distinction also keeps the headline from becoming a misleading token claim. A 16.4% share of estimated cost is different from a 16.4% share of tokens. Model selection, input and output pricing, and caching conditions matter when interpreting the result.
The comparison with the main conversation is striking, but that category is only one part of the deployment’s activity. It does not mean status summaries cost more than all useful agent work combined.
Why a Short Status Line Can Require Substantial Input
According to Flamerix’s description, Claude Code sends each background agent’s full transcript to that agent’s model approximately every 30 seconds. The request asks it to:
“describe your most recent action in 3-5 words”
The response updates the agent’s status line in the agents panel. Flamerix says it does not become part of the working conversation or feed back into the agent’s task context.
That mechanism explains the approximately 9,000:1 input-to-output ratio: producing a tiny answer can still require processing a large transcript. In Flamerix’s measurements, almost all summary spending was on Opus.
The resulting cost depends on more than the number of status words. The number of active background agents, their running time, transcript lengths, model choices and cache behavior can all affect the workload. Repeated summarization creates more opportunities for overhead as a team runs more agents in parallel.
My view is that the useful finding here is the separation between task work and interface maintenance. A status label can help users follow parallel work, but its cost deserves its own telemetry category. Output length alone is a poor guide to that cost.
Anthropic Reports Lower Usage and a Cache Fix
Anthropic’s Hacker News response gives two broader reference points: about 2% of cost across users sharing telemetry and about 6% in terminal usage, calculated at API list prices.
Those figures are company-reported telemetry, not independent measurements. They also describe different populations from Flamerix’s single team.
| Reported cost share | Population or workflow |
|---|---|
| 16.4% | Flamerix’s measured week, characterized as background-agent-heavy |
| About 2% | Anthropic’s telemetry-sharing users overall |
| About 6% | Anthropic’s terminal-usage figure |
The terminal figure is a useful additional comparison, but it still does not match Flamerix’s workload agent for agent. The published evidence does not provide a controlled comparison with identical versions, models, agent counts and transcript sizes.
AI Weekly’s account of Anthropic’s response also reports that a cache-miss fix shipped in Claude Code 2.1.311 and later. Anthropic said it was developing a cheaper approach that sends short notes to a smaller model.
Those are separate mitigations. A cache fix addresses an inefficiency in the existing path. A smaller-model approach changes the model and input used for the status task. The response gives no shipping date for that second change.
How to Check Your Own Claude Code Usage
Start with your installed version and a representative telemetry window. I’d check the version before considering a runtime workaround, because Anthropic’s reported cache fix changes the conditions under which earlier observations were made.
For teams already collecting Claude Code OpenTelemetry events, the Flamerix analysis provides a useful measurement pattern:
- Filter the right events. Examine
claude_code.api_requestevents and group them byquery_source. Identify requests labeledagent_summary. - Calculate estimated cost share. Sum
cost_usdfor summary requests, then divide by the sum for all Claude Code requests in the same window. Multiply by 100 for a percentage. - Calculate request share separately. Divide the summary-request count by the total request count. Flamerix’s 19.7% request share and 16.4% cost share show why these metrics are not interchangeable.
- Break down the model mix. Check which models handle summaries. Flamerix’s 96% Opus share was a share of summary spending, not a share of every Claude Code request.
- Record workload conditions. Note the Claude Code version, interface, background-agent activity and measurement duration. Compare periods with similar work.
- Review cache-related information where available. A request containing a large transcript does not, by itself, reveal its final cost under the applicable caching conditions.
Track absolute estimated cost alongside the percentage. A summary share can fall simply because other work becomes more expensive, even if summary spending stays unchanged.
For subscription accounts, keep the estimate separate from the bill. The useful question is how much usage capacity the feature consumes during your actual workflow.
The Workaround Targets the Timer
Flamerix’s gist includes an MIT-licensed Bun preload, no-agent-summary.js, that suppresses the recurring summary calls without modifying the Claude Code binary.
The current gist describes a wrapper around the global setTimeout function. It examines a timer callback’s source text for known summarizer markers. When it recognizes that callback, it returns an inert handle instead of scheduling the summary timer. Other timers pass through.
Frequently Asked Questions
3 questions
1Does the 16.4% figure apply to every Claude Code user?
No. It describes one team’s measured week. Anthropic reports about 2% across telemetry-sharing users and about 6% for terminal usage.
