Posted by NikZaal 2 hours ago
Our DRIM system flagged the anomaly in CC's OTEL traces. Grouping requests by query_source showed that over one measured week agent_summary accounted for: 16.4% of total estimated spend (versus 15.7% for the main conversation), and 19.7% of all API requests with approximately 9,000 input tokens per output token.
Most requests reuse the prompt cache, but repeatedly reading a large cached transcript still has a cost. Longer contexts and more concurrent agents increase the overhead.
We couldn’t find a supported setting that disables only these summaries while preserving background agents and forks. Disabling those capabilities also stops the summaries, but changes the workflow we want to keep.
Our workaround is a small Bun preload that intercepts the summary timer without modifying the CC binary. It identifies the timer callback by source-text anchors and leaves other timers alone.
In controlled tests on Linux (from ver 2.1.257 to 2.1.312), the same workload produced five summary calls without the hook and zero with suppression enabled. On our current production setup, agent_summary calls remained at zero with the hook enabled. Background agents and forks continued running. The only visible change was that their generated status summaries stopped updating.
The workaround depends on implementation details. An update can break the callback matching and silently restore the requests. macOS and Windows are untested. If someone could help us with testing there, it would be much appreciated.
If you want to try it - the script, full technical explanation, test results, and installation instructions are on GitHub: https://gist.github.com/flamerix-ai/c3905705cc4205e5de3011fa...
Your 16.4% sounds like it was for a team running mostly background agents, and doesn't seem like a typical session. (Feel free to send me the session ID at edwinarbus@anthropic.com and we can dig further.)
Last week, across Claude Code users who send us telemetry, agent_summary was about 2% of cost at API list prices and just under 4% of requests. In the terminal, where nearly all of these calls happen, it was about 6% of cost.
That said, we agree that's a lot for a status line. We just rolled out a fix for the most expensive case, summaries that miss the prompt cache (2.1.311+), and right now we're working on a much cheaper mode that sends short notes to a smaller model instead of the full transcript.