Claude Code burns ~15–20% of your tokens on a 3-word status line

Posted by NikZaal 2 hours ago

Counter161Comment37OpenOriginal

Comments

Comment by HeavenFox 1 hour ago

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?

Comment by minraws 57 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

Comment by simianwords 52 minutes ago

Isn’t it 0.2?

Comment by minraws 40 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

Comment by buzer 51 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.

Comment by maxbond 10 minutes ago

It's an hour. It'll tell you the expiry time on the status line now but that information is also available in /usage.

Comment by buzer 7 minutes ago

https://github.com/anthropics/claude-code/issues/46829

Looks like what I remembered was a bug.

Comment by dietr1ch 1 hour ago

Unless they prepend something like, "summarise this, "

Comment by NewsaHackO 58 minutes ago

But they definitely wouldn’t do that.

Comment by gym 1 hour 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.

Comment by bombcar 59 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.

Comment by adastra22 57 minutes ago

I assume that is only if compact is turned on? I never use compaction.

Comment by SyneRyder 25 minutes ago

They enabled it for everyone in a recent Claude Code update, but you can turn it off (I did).

I am definitely getting frustrated with a lot of the changes they keep making in Claude Code. It's one thing to find settings have changed during your next interactive session, it's another when it changes how overnight unattended sessions behave. I really should be spending more time building my own harness again.

Comment by Matticus_Rex 22 minutes ago

Check your idleCompaction line in /config to make sure it's off -- several times they've toggled new features on by default for me. This one isn't in the VS Code extension so I don't know if it shipped default-on.

Comment by OsrsNeedsf2P 1 hour ago

This is an A/B test

Comment by grim_io 1 hour ago

More likely it depends on the overall load of the infrastructure.

Comment by jakozaur 46 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.

Comment by lemming 38 minutes ago

I mean… 8% still seems pretty indefensible, especially if you can’t turn it off. That’s a big chunk of usage.

Comment by chii 34 minutes ago

any % is indefensible, because this should be user toggled. It's an unnecessary money burner.

Comment by _boffin_ 20 minutes ago

Just looked and we're burning around ~3%, but that's across everything / everyone.

Comment by creamyhorror 54 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!

Comment by ab_wahab01 20 minutes ago

Does this happen in the VS Code extension? or only in the terminal?

Comment by apt-apt-apt-apt 1 hour ago

At least they seem to have fixed their free-revenue feature-bug, where they randomly invalidate your cache (~$8 a pop (turn))

Comment by lifeisloving 57 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.

Comment by rurban 10 minutes ago

That's why people are using pi, not Claude. What a waste of money

Comment by leroman 14 minutes ago

At the base there is a conflict of interests- what we pay for

Comment by messh 1 hour ago

Bloat. I like Pi much better with it's minimalism

Comment by fractorial 43 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.

Comment by quantbuilder 1 hour 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?

Comment by simianwords 55 minutes ago

Isn’t this prompt cached? Then it’s not that big of a deal

Comment by rsalus 1 hour ago

does this happen for Claude Desktop too?

Comment by 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 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...

Comment by edwinarbus 42 minutes ago

I work on Claude Code. You've got the basic mechanism right, but to be super clear, this only applies to background agents that are actively working. They get a summary call about every 30 seconds, and idle background agents don't. These summaries are used for both you and Claude Code to track what each background agent is working on, without reading transcripts.

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.

Comment by digitaltrees 38 minutes ago

It’s almost like they are trying to go public. Burn those tokens.

Comment by helsinki 1 hour ago

I’m sure they release a decision model that alleviates this problem in due time.

Comment by hypfer 9 minutes ago

With the ever-increasing amount of paper cuts one gets from using their products, I wonder how long this will really go on?

After all, for most of the work people seem to be doing daily, Claude kinda isn't.. necessary? In fact, for a lot of tasks, not using it leads to better results in my experience.

There are things that only it can reasonably accomplish, but if every interaction with it hurts you in various ways (like this one), then, eventually, I do not see that working out for them anymore.

But perhaps this is just a way to push the numbers a bit further up for the IPO? That would make a lot of sense to me.

Comment by jitl 5 minutes ago

i use opus 5.5 to delegate to sol and luna via codex-thread-bridge (https://github.com/saidelike/codex-thread-bridge). these days i’m experimenting with opus using luna as “hands” and it’s largely resolved the tokens per output issue with my Anthropic subscription.

¯\_(ツ)_/¯ it’s not efficient but yeah it’s the best