If they are literally sending the entire transcript and asking for a summary, wouldn't almost all of the tokens be cache hit, and therefore fairly cheap?
minraws 28 minutes ago [-]
I don't want to sound rude but even at cache hit you are burning almost input * 0.10 * context amount of tokens multiple times.
If it happens 10 times you have already accepted the same cost as the entire session fresh prefill.
People on HN are either too rich or wayyy too rich
simianwords 23 minutes ago [-]
Isn’t it 0.2?
minraws 10 minutes ago [-]
It's 0.1 I think brain fart I typed the rest correctly though after 10 summaries you still burn the same amount of tokens
buzer 21 minutes ago [-]
Didn't they change the cache TTL to 5 minutes earlier this year? So depending on exact timing it could potentially be invalidated between the updates.
dietr1ch 34 minutes ago [-]
Unless they prepend something like, "summarise this, "
NewsaHackO 28 minutes ago [-]
But they definitely wouldn’t do that.
jakozaur 16 minutes ago [-]
I tested it, and it looks real but more nuanced. It is just for subagents; workflows do not seem affected. I guess many new users prefer workflows (ultracode), so the impact is less than the report suggested.
Moreover it is mostly cached reads, so subagents with short context cost little, while long-context ones cost much more.
In my Claude Code sessions, it looks more like ~8% at most.
lemming 8 minutes ago [-]
I mean… 8% still seems pretty indefensible, especially if you can’t turn it off. That’s a big chunk of usage.
chii 4 minutes ago [-]
any % is indefensible, because this should be user toggled. It's an unnecessary money burner.
gym 37 minutes ago [-]
I was surprised the usage issue wasn't mentioned here before this based on my searching on hn.algolia.
I'm on pro. Two days ago, 100% 5 hour was using 25% of my weekly. Today, 100% 5 hour is like 13% so something was fixed.
bombcar 29 minutes ago [-]
They very aggressively compact when the cache is about to expire, which saves a ton of tokens, the equivalent of doing a handoff at 25% or less.
adastra22 27 minutes ago [-]
I assume that is only if compact is turned on? I never use compaction.
OsrsNeedsf2P 33 minutes ago [-]
This is an A/B test
grim_io 30 minutes ago [-]
More likely it depends on the overall load of the infrastructure.
creamyhorror 25 minutes ago [-]
Background agents only have 5 minutes' cache TTL, but I'm guessing this doesn't help extend it (not that it would be too useful anyway, especially considering the extra burn).
Also, the claim "15-20% of your tokens" seems unclear; of all tokens, or of tokens spent on background agents? Poorly edited AI writing strikes again!
apt-apt-apt-apt 33 minutes ago [-]
At least they seem to have fixed their free-revenue feature-bug, where they randomly invalidate your cache (~$8 a pop (turn))
lifeisloving 28 minutes ago [-]
This is by design, its the same reason inference providers on Openrouter will advertise super cheap pricing but cache TTLs of 2 min/ 70% hit rate.
Cache rules everything around me.
digitaltrees 8 minutes ago [-]
It’s almost like they are trying to go public. Burn those tokens.
messh 47 minutes ago [-]
Bloat. I like Pi much better with it's minimalism
fractorial 13 minutes ago [-]
As someone who rolled and daily drives a harness leaner than Pi, there’s still a use case for both.
Similarly to “one language is best,” saying “one harness is best” is shortsighted in the best possible case.
That being said, Claude Code is bloatware.
quantbuilder 44 minutes ago [-]
i think its not the status line at the bottom of the terminal, but actually the few words summary claude generates for each background agents in the agents panel. so if we mostly run one plain session we wont pay for this? i do run claude code with disableAgentView on in my settings. does anyone know if that helps to stop the summary calls or just hides the panel?
helsinki 42 minutes ago [-]
I’m sure they release a decision model that alleviates this problem in due time.
simianwords 25 minutes ago [-]
Isn’t this prompt cached? Then it’s not that big of a deal
rsalus 44 minutes ago [-]
does this happen for Claude Desktop too?
NikZaal 2 hours ago [-]
Claude Code's (CC) status summaries used 16.4% of our token spend in a week! We have investigated a source of overhead in CC: it's an agent_summary query that calls your current session/subagent model approximately every 30 seconds for a few words in CC’s status line.
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 it happens 10 times you have already accepted the same cost as the entire session fresh prefill.
People on HN are either too rich or wayyy too rich
Moreover it is mostly cached reads, so subagents with short context cost little, while long-context ones cost much more.
In my Claude Code sessions, it looks more like ~8% at most.
I'm on pro. Two days ago, 100% 5 hour was using 25% of my weekly. Today, 100% 5 hour is like 13% so something was fixed.
Also, the claim "15-20% of your tokens" seems unclear; of all tokens, or of tokens spent on background agents? Poorly edited AI writing strikes again!
Cache rules everything around me.
Similarly to “one language is best,” saying “one harness is best” is shortsighted in the best possible case.
That being said, Claude Code is bloatware.
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...