Systima put a proxy between each CLI and the Anthropic endpoint and logged actual HTTP payloads, finding Claude Code ships ~33k tokens on turn one versus ~7k for OpenCode on identical work. They argue this 26k baseline gap is harness scaffolding — system prompt, tool schemas, environment context — that the user never sees but pays for on every interaction.
The editorial emphasizes that Systima's methodology — logging raw HTTP payloads rather than inferring from Anthropic's usage dashboard — is the reason the finding sticks. It moves the argument from marketing claims to reproducible packet captures, and the HN thread shows others running their own tcpdumps landing in the same 30k-ish neighborhood.
The editorial concedes Anthropic's cached-input pricing (roughly 10% of fresh tokens) meaningfully reduces the API-cost sting after the first turn. But it argues caching doesn't recover context-window headroom — every three-character typo fix still burns 33k tokens of the window before the model reads your prompt.
Systima, a small shop that normally lives in OpenCode, got pushed onto Claude Code for a stretch while their usual setup was broken. They noticed the Anthropic usage meter climbing far faster than it did on equivalent work in OpenCode. Instead of shrugging, they put a proxy between each CLI and the Anthropic endpoint, captured every request byte, and counted.
The numbers, from their write-up: Claude Code sends roughly 33,000 tokens on the very first turn — before the user prompt is even read. OpenCode, on the same task with the same model, sends around 7,000. That's a 26k-token baseline gap, per request, on every interaction in a session. The overhead is system prompt plus tool schemas plus environment scaffolding — the harness the agent runs inside — not anything the developer typed.
Systima's methodology is the important part: they didn't infer from the meter, they logged the actual HTTP payloads. That takes the argument out of the marketing layer and puts it on the wire, where it's checkable. The Hacker News thread (632 points at the time of writing) is full of people running their own tcpdumps and landing in the same neighborhood — 30k-ish for Claude Code, single-digit-thousands for the leaner harnesses.
Agentic coding tools are sold on capability. What Systima's measurement exposes is that capability has a fixed cost baked in before you say anything. Every "fix this typo" request in Claude Code is a 33k-token conversation starter, even if the fix is three characters. On a Sonnet-priced session that's real money; on a session where you're pushing toward the context window, it's real headroom you don't get back.
Anthropic will (correctly) point out that prompt caching exists and that the system prompt block is a cache-hit after the first request. That's true, and it takes the API cost of the overhead down substantially — cached input tokens are roughly a tenth of the price of fresh ones. But caching doesn't fix three other problems. First, latency: the model still has to attend over the whole prompt on every turn, and 33k tokens of attention isn't free even when the bytes are cached. Second, context budget: your working context is finite, and every token the harness eats is a token your codebase doesn't get. Third, cold starts and cache eviction — every new session, every 5-minute idle gap on the default TTL, and you're paying full freight again.
OpenCode's 7k number is instructive because it shows the overhead is a design choice, not a physics constraint. The two tools solve similar problems. One decided to ship a maximalist system prompt with dense tool schemas and elaborate behavioral scaffolding; the other decided the model could figure most of that out on its own. The gap between them is the price of "batteries included" measured in tokens, and until this week nobody had actually printed the receipt.
The reactions from practitioners on HN split cleanly. One camp says Claude Code's overhead buys real capability — the tool-use is more reliable, the file-editing is more precise, the guardrails catch more mistakes — and the price is worth paying. The other camp says they've been running OpenCode or their own thin wrappers for months, getting 80% of the outcome for 20% of the token spend, and Claude Code's overhead is what a mature product looks like when nobody on the team is measuring waste. Both camps are probably right, for different workloads.
If you're on a Claude Max plan or a flat-rate seat, the token accounting doesn't hit your card directly, but it hits your rate limits and your context window. If you've been noticing that Claude Code seems to "forget" earlier files in long sessions faster than you'd expect, you now have a number: 33k tokens of your window is spoken for before turn one, and it grows from there.
If you're paying per-token through the API — via a team plan, a Bedrock deployment, or your own key — this is the difference between a bearable line item and a surprising one. A team doing 500 agent turns a day is shipping roughly 13 million baseline tokens of pure harness overhead per day on Claude Code, versus 3.5 million on OpenCode. Cache that aggressively and the delta shrinks, but it doesn't disappear, and the discipline of keeping the cache warm is its own operational cost.
Practical moves, in order of effort. Short term: turn on prompt caching if you're API-direct and you haven't (it's a header, not a rewrite). Medium term: run Systima's proxy trick on your own workflow for a day and see what your actual overhead is — the numbers vary by tool version and configuration and are worth measuring against your own baseline, not somebody else's blog post. Longer term: if you're at a scale where token spend is a real line, evaluate OpenCode, Aider, or a thin homegrown harness for the classes of task that don't need Claude Code's full capability surface. Keep Claude Code for the hard work; use something leaner for the boilerplate.
The interesting thing isn't that Claude Code is heavier — that was already the vibe. It's that somebody bothered to measure it, and the measurement is reproducible. Expect the next round of agent tooling to compete on token efficiency as a first-class metric, the way web frameworks eventually started competing on bundle size after everyone got tired of shipping megabytes. Anthropic will probably respond by slimming the default system prompt, or by making the heavy scaffolding opt-in per task. The teams that quietly benchmark their own harnesses will be the ones who know whether the response is real or cosmetic.
This 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
→ read on Hacker NewsMy 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.
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 resu
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
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...
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
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 pro