Hacker NewsThis started based off of a hunch. We usually use OpenCode, but were 'forced' to use Claude Code for a while due to issues with Meridian. In that time, we saw the usage meter rise much, much more quickly than when using OpenCode.
This was the initial anecdotal evidence, but we undertook this small study to collect empirical data:
We added logging between the agentic coding tool (Claude Code and OpenCode) and Anthropic's endpoint, and captured all requests (and the returned usage blocks).
With one caveat (toward the end of the post) we found unambiguously that Claude Code was far more inefficient in terms of its cache strategy and its harness token usage than OpenCode.
Comments URL: https://news.ycombinator.com/item?id=48883275
Points: 504
# Comments: 282
Hacker News 讨论
504 points · 282 comments · 查看原帖
- mcv
What really burns tokens is sub agents. I once gave Claude Code a pretty big task, and it immediately launched 7 sub agents which burned through my budget before even one of them was finished. Tried again 5 hours later: same result. If I let the main agent do the same task sequentially, it was no problem at all. I don't know if it's really just communication and orchestration that makes sub agents so inefficient, or if Anthropic figured that most people using sub agents pay per token on a big corporate account, so this is an easy way to make more money from tokenmaxxers.
- korrectional
My opinion is that claude code uses more tokens simply because Anthropic makes more money that way and forces people into their subscriptions. This is supported by the fact that they won't let you use your sub on a different coding agent. I use pi btw.
- systima
UPDATE: After reading PUSH_AX's valid comment: ``` This is like saying contractor (A) asked for $33,000 to undertake the work and contractor (B) asked for $7,000 Are we measuring and caring about the right thing? ``` We will update the post to include: 1) A more in-depth task. 2) Qualitative results comparison. 3) As soon as possible, a reproduction of the inputs and outputs.
- jakozaur
This isn’t limited to large system prompts. Coding-agent harnesses are also becoming more aggressive about using tools, even for trivial requests. In our tests, prompts such as “Hey” or “commit” sometimes triggered 30+ tool calls: https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-... Tokenflation seems very real: the number of tokens consumed by simple tasks keeps increasing.
- bel8
And pi agent is even less. The entire agent system prompt can be seen here: https://github.com/earendil-works/pi/blob/main/packages%2Fco...
- estetlinus
Recently switched to Codex after 6m in Claude. Codex seems more open, it’s easier to follow what the model is doing and the approvals have a better UX. Overall, it just feels more transparent. Cost of switching was close to 0. I don’t like that Claude became more opaque around February, including the system prompts. 33k feels way too much.
- overgard
I've been using Claude since January, and whenever I run CCUsage I've been noticing the overall cost creep up pretty much every month. (I'm on a subscription so this would be the hypothetical billing if I were on API prices I suppose. Although I don't really want to test that with my credit card.) The funny thing is the first few months I was token-maxxing as hard as I could just to see how awful of a bill I could run up (mostly as a curiosity thing). At this point the novelty of doing that has worn off for me, but even with me being pretty conservative in my usage now the cost is way higher. I think I was spending like $12 a day in january, and now I'm easily spending $60+ a day in part time work. The amount of work I've been doing has stayed relatively constant (I'm not trying to run agents in parallel or loops or whatever fancy new ways there are to burn money, this is the same workfl
- GodelNumbering
It is not the raw prompt size that matters ultimately, otherwise Pi (and variants) would be the lowest costing agents. What matters is how efficient the prompt it. Prompt minimalism often gets conflated with efficiency. Having said that, CC does seem bloated for what it does. What matters even more is tooling quality. Bad/buggy tooling causes a lot more roundtrips that wipes out all gains from initial greedy approach. A few months ago, I did a full benchmark run of 7 agents over 8 tasks ( https://github.com/dirac-run/dirac has the data and traces). I cannot claim neutrality because of the obvious connection to one of those, but the data should be reproducible and useful. Importantly, Dirac wins there significantly on those tasks because they are mostly refactoring related (which is where approaches like hash-anchoring and AST parsing tend to shine)