Claude Code Sends 33,000 Tokens Before It Reads Your Prompt. OpenCode Sends 7,000.

TL;DR

Consultancy Systima put a logging proxy between two coding agents and the Anthropic API and published the exact payloads on July 12. Before your prompt contributes a single token, Claude Code ships roughly 32,800 tokens per first request; OpenCode ships about 6,900 for the identical task on the identical model. The sharper finding sits one layer down: Claude Code's request prefixes are not byte-stable, so across a five-request session it wrote 53,839 cache tokens where OpenCode wrote 1,003. Before you rage-uninstall anything, read the counterevidence, because on a real write-run-test-fix task Claude Code finished in fewer requests and fewer cumulative tokens. The Hacker News thread hit about 430 points and 240 comments in its first day.

How they measured it

The setup is the same shape as last week's Grok Build teardown: don't ask the vendor, read the wire. Systima ran Claude Code 2.1.207 and OpenCode 1.17.18 with both harnesses pinned to Claude Sonnet 4.5, captured every request through a local proxy, and logged the payloads into a hash-chained audit trail (185 entries, chain verified). Three tasks: T1 asks for a bare "OK" reply, T2 summarizes a file, T3 is a write-run-test-fix loop.

On T1, the task where the model needs nothing but a system prompt and four letters, Claude Code's request weighed in at roughly 32,800 tokens and OpenCode's at about 6,900. That is a 4.7x gap for an identical outcome on an identical model. A validation pass on Claude Fable 5 narrowed it to roughly 3.3x, mostly because the harness ships Fable a much shorter system prompt (about 10,500 characters against roughly 27,000 on Sonnet).

Where the 33,000 tokens go

The breakdown is the part worth internalizing, because the headline invites the wrong conclusion. Claude Code's system prompt is about 6,500 tokens. The bulk of the overhead, roughly 24,000 tokens, is the JSON schemas for 27 built-in tools, plus around 8,000 characters of first-message scaffolding. OpenCode gets by on about 2,000 tokens of system prompt and 4,800 tokens across 10 tools.

So Claude Code arrives at a "reply OK" task carrying 27 tool definitions, which is the agent equivalent of bringing a ladder, a torque wrench, and a wet saw to change a lightbulb. To be fair, it does not know it is a lightbulb job yet. That is the design tension: a harness that might need NotebookEdit on turn nine has to decide whether to pay for it on turn one.

The cache plot twist

The obvious rebuttal, and half the HN thread made it, is that a big static prefix is nearly free once prompt caching kicks in: cache reads bill at a tenth of base input price. But caching only discounts a prefix that repeats byte-for-byte, like a barista who remembers your order only if you recite it identically every morning. Change one word and you are a stranger paying full price for the latte.

That is where the capture gets uncomfortable. Systima found OpenCode emitted byte-identical prefixes across every request and every run. Claude Code emitted three distinct request classes per session, varied its system bytes between sessions, and varied its first-message scaffolding between runs. Result: across an identical five-request session, Claude Code wrote 53,839 cache tokens against OpenCode's 1,003. Cache writes are the expensive kind, billed at 1.25x base input on the default five-minute tier and 2x on the one-hour tier, so prefix churn is a surcharge, not a rounding error.

Before you rage-switch harnesses

The study is more honest than its headline, and the honest parts cut the other way. On T3, the multi-step loop, Claude Code batched tool calls and finished in 3 requests totaling about 121,000 cumulative tokens. OpenCode serialized its calls and took 9 requests (plus a title call) totaling about 132,000. The fat harness won the realistic task. Per-request overhead compounds with request count, and the harness that thinks in bigger steps sends fewer of them.

Configuration swamps both baselines anyway. A 72KB instruction file added roughly 20,000 tokens to every request on either harness, and a five-server MCP lane added another 4,900 to 6,967. In the one full production config Systima measured, OpenCode's cold request was actually the bigger one, 90,817 tokens against Claude Code's roughly 75,000, though that practitioner ran eleven MCP servers on OpenCode and four on Claude Code, so treat it as an illustration, not a verdict. And subagents dwarf everything: delegating the T3 work to two subagents burned about 513,000 tokens against 121,000 done directly, a 4.2x multiplier, because each subagent re-reads context the parent already paid for.

Quality, for once, is not the confounder: both harnesses completed every scored task correctly. As the authors put it, the token gap is the cost difference for an identical outcome. Caveats are stated plainly too: one machine, one version pair, two model families, small sample sizes, a local gateway in the measurement path, and prompts that change often enough that this is a July 2026 snapshot, not a law of physics.

What the thread added

The HN discussion supplied useful corroboration and pushback. One commenter noted a fresh session's /context display attributes only about 4k tokens to the system prompt, which matches the study's breakdown: the floor is mostly tool schemas, not instructions. Others pointed out that if the richer toolbox improves outcomes even slightly, a cached 33k prefix pays for itself within a few turns. Several users reported the subagent burn independently, one describing seven subagents exhausting a budget before finishing, and a few said they had already moved daily driving to OpenCode or Codex over cost transparency. Anthropic had not responded as of Sunday evening UTC; the tokens, presumably, keep shipping.

What to actually do about it

• Run /context and look at the composition of your own first turn. Tool schemas and MCP servers are the levers; the system prompt mostly is not.
• Prune MCP servers you are not using this session. Each one you carry is paid on every request, and at cache-write prices whenever the prefix churns.
• Weigh instruction-file size. A 72KB CLAUDE.md or AGENTS.md is a 20k-token tax per request on any harness.
• Treat subagents as a deliberate spend, not a default. The 4.2x multiplier is the largest number in the whole study.
• If you run high request volumes through thin per-request tasks, the per-request floor dominates and a lean harness genuinely is cheaper. If you run long agentic loops, batching dominates and it probably is not.

Key Takeaways

• A proxy capture published July 12 measures Claude Code's first-turn floor at about 32,800 tokens versus OpenCode's 6,900 on the same model and task, a 4.7x gap (3.3x on Claude Fable 5).
• Roughly 24,000 of those tokens are schemas for 27 built-in tools; the system prompt itself is about 6,500.
• Claude Code's prefixes are not byte-stable, producing 53,839 cache-write tokens across a five-request session where OpenCode produced 1,003, and writes bill at a premium.
• On a realistic multi-step task the result flips: Claude Code's batching finished in 3 requests and about 121,000 cumulative tokens against OpenCode's 9 requests and 132,000.
• Real-world config dominates both baselines: a 72KB instruction file costs about 20k tokens per request, MCP servers stack on top, and two subagents multiplied one task's spend 4.2x.
• Both harnesses completed every scored task correctly, so the gap is pure cost, and the right harness depends on whether your workload is many thin requests or few fat loops.

Sources: Systima, "Claude Code vs OpenCode: token overhead", Hacker News discussion, Anthropic prompt caching docs