Claude Code regularly sends each background agent’s transcript to its model
j / k
|
Down or up a comment |
h / l
|
Previous or next link |
?
|
This help |
https://www.reddit.com/r/ClaudeCode/comments/1xhqvzn/opus_55...
You can remove it with a simple plugin https://github.com/AlexErrant/claude-code-no-email/blob/main...
1. It was said to be required (e.g. Searching through SEC)
2. Politeness policy (Wikimedia's bot policy and Crossref's "polite pool" ask automated clients for contact details)
So I think it wasn't because of malicious reasons as far as I can tell.
I did instruct Claude to never do it again except for the politeness policy. I'm assuming WikiMedia requested this so that they have someone to contact in case a bot overloads their servers
If not... That sounds like primetime for prompt injection.
There are better ways to do this, they just haven’t been built yet.
Eg this may not need actual contact info. Wikipedia just wants a way to ask you to stop. Anthropic could add an opaque agent/session identifier that Wikipedia could flag, and Anthropic just forwards that on to you in the UI.
If you don’t have free text fields it’s usually not super useful for spam. There are ways to get a binary “good/bad” signal back without that though.
I caught it sending my email to two non-Wikipedia/SEC sites (which I won't specify because they're work related.) I only found out because I held a "retro" with the agent, then found the other session after grepping my logs.
I'm on the 20x Max plan and my quota is at 98% (resets today), so I had a quite heavy week of usage, including a bunch of orchestrated subagent runs (no workflows).
API equivalent spending for this week: $1,970
Hidden status-label calls: ~$380
Share of the true total: 16%
That's incredible...
For example last week I put $1400 thru my Anthropic enterprise $200 plan. That's $5600 per month, or 28X the $200 my company pays (according to `npx ccusage`)
Time to start questioning the motivations of model providers shipping their own harnesses.
I don't understand this "analysis". Why would it not be about profit?
"Features for internal users" makes no sense here, as it does not apply to the case. "Useful features" is also debatable - LLMs providing user data upstream to Anthropic is a use case for Anthropic, but less so for downstream users and token burners.
I’m much more inclined to believe they just don’t _care_ about cost, and profit is an ancillary benefit to their functionality above all else.
Just recently they released auto idle-compaction for large sessions about to miss the cache window. If they were so profit driven I can’t imagine they’d have built this to begin with, that’s free tokens from your perspective.
Hahaha good one. Profit is the whole reason of existence for for-profit companies. Sure, companies might start with some ideologic grain of thought. But as soon as you reach a certain size, all that goes flying out of the window.
I run three 20x max accounts to 100% every week. I could easily use more if I could afford it.
And obviously they wouldn’t IPO if they didn’t need to raise cash, but have you read the S1?
You could decide where most work.
I don’t know if there’s any openly available statistics on how API costs divide between Claude Code, Claude SDK, raw API, and via OpenRouter.
Maybe we'd have local models ...
I’m sure there’s some galaxy brain theory for why they’d want to keep costs high and reduce value rather than just having an efficient harness and reducing quotas by this 16%, which would be identical for users and save money.
But a far more likely explanation is: a dumb bug.
Claude Code is a shitty harness.
What is the best drop-in OSS replacement that has support for skills and mcps?
I think omp.sh (oh-my-pi) is the best by a comfortable margin and its completely batteries included. It will pick up and use your Claude Code skills and plugins by default.
If you like to customize your tools Pi is the best, it has a huge plugin ecosystem (all can be used in OMP as well, but it has opinionated answers for most things already). Stay away from OpenCode, its a pile of slop like Claude Code.
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
But if you are telling me I am wasting like a good 10-20% of my tokens on summaries I might as well stop using your service, worst part is claude doesn't let you use something else.
If they were doing that, then a cheaper (prompt-cache friendly) option is just to silently send the whole conversation with the summariser prompt appended
Looks like what I remembered was a bug.
Do you disagree with the numbers and conclusion in the -pretty obviously bot-generated- Fine Article?
And I don't really get the point of this feature, I've always found it super annoying that the main agent creates a subagent with the clear description of "Fix tile cache" for example, and then after a while it turns into something generic like "Running browser tests"
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.
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.
Read your memory.md to see what Claude thinks is very important.
I'm mostly working on moderately sized rust codebases (600k~ lines) with reasonably long running tasks. The only time I intentionally do a handoff is if the next goal is in an entirely different section of the code, or I let the session cache expire, or I'm working with 6.1 Sol for more than a few hours, which admittedly has some horrendous context drift compared to Opus.
They’ve got that IPO coming up so they’re turning up the fraud in preparation.
There’s something reassuring about seeing the true hacker spirit still at work here.
I approve.
https://gist.github.com/flamerix-ai/c3905705cc4205e5de3011fa...
Maybe. But the 16.4% is from Claude Code's own cost_usd estimate, so cheap per token still adds up when it's 1 in 5 requests.
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.
Cache rules everything around me.
$100 on DeepSeek has lasted over a week, whereas on OpenRouter it lasted two days
That eventually grew into what is now my 'software factory' and I've realized, eventually, it's still C.R.E.A.M. (I named it flower) but it's _context_ rules everything around me.
The notable discovery here isn't that the AI agent has access to its own transcript, it's that 20% extra tokens are used to generate the status line. Leave it to LLM writing to focus on something inconsequential though.
The model maker has zero incentive to prioritize efficient token use.
It's actually not super difficult to "decompile" it, tweak some stuff, and recompile. I use this method to change some ridiculous hardcoded instructions in the system prompt.
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.
You are arguing against something that was not said?
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!
The code I own professionally has LOC in the 6 figures, and it's near impossible to hit weekly quota unless I'm running a bunch of experiments on the side or using Fable for everything
Probably a different story when the codebase is much larger
I was handed 150$/mo budget and no subs, and while it was frustrating at first, with better tooling, context management and especially OAI models it's a breeze now and not even using 70% mostly while achieving a lot in a small team.
Having limited resources teaches you a lot.
It's great that the project/team you were in had skills/cycles to do it.
In many cases this is pure yak shaving so to speak. Consider an embedded project where there are tons of tedious things to be tied together; Also, the project velocity is more important than saving another 1k per year. The decision not to switch is the smart choice in many cases.
Absolutely.
Otherwise, it’s just obfuscated spyware that inserts ads into Git commits by default, and has been shown to consume far more tokens than other harnesses for the same tasks and models.
I really see no valid reason to use it. I tried a recent version to see whether things had changed since last year, and it’s just even more bloated.
I hope Anthropic's next model is capable of better writing.
I find the way it adds this unnecessary "own" very grating in explanations.
For example: "Two benchmarks, each with its own score".
Of course the author could also just write at least the summary himself.
Sorry, bad day...
One can reason that it is useful, e. g. saves the time of people (see how Claude is now the number #1 committer in Ruby) but ultimately all that data is used by private companies, making them richer in the process. So, first you pay for the tokens; and then others benefit from it without giving you any money. It is a brilliant scheme since it works so well. People are sold to their AI overlords now.
It's the same addiction script again and again.
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.
Also why you're so dismissive with the 2/4% figure while completely ignoring the TFA analysis and the other examples in their linked github issue?
Seriously, you're adding a feature that silently burns 15-25% tokens (that is burning money for API clients), and take away everything that could be used to mitigate it, and your response is basically, "eh, your numbers are unimportant and ours say it's negligible but since you complain we'll make it a bit cheaper".
Seriously, that looks so intentionally customer-hostile and revenue-friendly, but reading the room no one is surprised.
Are you aware of any updates on the SDK using more session usage vs claude code (https://github.com/anthropics/claude-code/issues/97074)?
I also wonder if the fix that they "just rolled out" is actually activating the 'short' mode that TFA mentions...
[0] <https://code.claude.com/docs/en/statusline#how-status-lines-...>
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.
¯\_(ツ)_/¯ it’s not efficient but yeah it’s the best