Claude Code vs OpenCode: Why One Burns 4.7x More Tokens

Every agentic coding harness pays a fixed cost per API call before the actual task begins. That cost is the system prompt describing how the agent should behave, plus the JSON schema for every tool it's allowed to call, plus whatever the harness injects to keep long sessions on track. None of it is optional and none of it is visible unless you go looking with a proxy that logs the raw request.

The measurement found:

Two things stand out. First, the character-level breakdown roughly reconciles with the token totals: tool schema plus system prompt characters divided by a rough 4-characters-per-token ratio lands close to the reported token counts for both tools, which is a useful internal-consistency check on the measurement. Second, the cache-write disparity is an order of magnitude larger than the raw preamble gap, which means something beyond the static preamble is driving cost on repeat calls. That's the part most teams miss when they eyeball the 4.7x headline and assume it's the whole story.

Three components make up the preamble, and they don't scale the same way.

System prompt. The fixed instructions describing how the agent should behave, what tone to use, how to handle destructive operations, and how to reason about multi-step tasks. This is the smallest of the three components in both tools, and it's also the one that moves fastest: Anthropic said in early July 2026 that it had cut Claude Code's core system prompt by roughly 80%, from about 800 to about 164 tokens, for its most frontier model tier, on the theory that a lot of the defensive instruction language that accreted to keep weaker models in line is now a tax the newest models don't need. Older model tiers reportedly kept the fuller prompt. That change is real, but it's narrow: it touches the smallest of the three preamble components, not the tool schemas that make up the bulk of the gap.

Tool schemas. Every tool the agent can call needs a name, a description, and a full JSON schema for its parameters, and all of it ships on every request regardless of whether the model uses that tool this turn. This is where most of the 4.7x gap actually lives: Claude Code's 27 tools against OpenCode's 10 is already a 2.7x difference in tool count, and Claude Code's schemas run more verbose per tool on top of that, landing at a 4.8x gap in raw characters.

Injected reminders. Claude Code adds roughly 8,000 characters of <system-reminder> style scaffolding that doesn't appear in OpenCode's preamble at all. This is the harness re-asserting context mid-session (state of the todo list, security reminders, formatting rules) rather than trusting the model to hold it across turns. It's a deliberate reliability choice, not an oversight, but it's also pure token cost with no equivalent line item on the OpenCode side.

If you're already fighting token bloat from custom MCP tool integrations layered on top of either harness, the code-execution pattern that cuts MCP tool-schema tokens by up to 98% attacks the same category of cost from the tool-schema side rather than the base-harness side.

It's tempting to read "4.7x more tokens" as evidence that Claude Code's core instructions are bloated. The character-level breakdown says otherwise: system prompt size differs by 2.9x, tool count by 2.7x, but tool schema size differs by 4.8x, the largest gap of the three and the one closest to the headline ratio. Tool schemas are where the overhead concentrates.

That tracks with what each tool is built to do. Claude Code ships dedicated tools for notebook editing, structured task tracking, background process management, and MCP-aware tool discovery, on top of the standard file and shell primitives. OpenCode's roughly 10 built-ins (read, write, edit, bash, grep, glob, plus a handful of task and search helpers) cover the same core loop with less specialization. Neither is wrong. A narrower tool surface means the model composes primitives to do things a dedicated tool would do in one call, which trades token overhead for turn count. A broader tool surface means fewer round trips per task, at the cost of describing 27 tools' worth of parameters on every single request whether or not most of them get used.

For teams evaluating tool footprint as part of a broader agent-tooling decision, this is one input among several: our comparison of Claude Code, Cursor 3, and Codex CLI on parallel-agent workflows covers how tool breadth interacts with multi-agent orchestration specifically, which is a different axis than raw preamble size.

The 4.7x figure describes cold-start overhead. The number that should actually worry you if you're running either tool across a team is the cache-write disparity: 53,839 tokens for Claude Code versus 1,003 for OpenCode on the same calibrated task.

Prompt caching exists specifically so static preamble (system prompt, tool schemas) doesn't get re-billed at full input price on every turn of a session. It gets written to cache once, then read back at a steep discount on subsequent calls, as long as the cache entry is still warm. The catch: a cache write still costs more than a cache read, and every fresh session, every cache expiry, every context edit that invalidates the prefix, and every subagent spawn triggers a new write. A preamble that's 4.7x larger doesn't cost 4.7x more to write to cache; the measurement found it cost roughly 53.7x more, which suggests the dynamic, per-session portions of Claude Code's preamble (the injected reminders, the state that gets re-asserted rather than cached once and reused) are doing a lot more of the damage than the static system prompt and tool list alone.

Illustrative math using a mid-2026 Sonnet-tier cache-write rate around $3.75 per million tokens: the 52,836-token delta between the two tools' cache writes costs roughly $0.20 per fresh session on Claude Code versus roughly $0.004 on OpenCode, on identical work. That's a rough, clearly-derived estimate from the measured token delta, not a quoted client bill, and your actual rate depends on which model tier and pricing period you're on. But the shape of it, a two-order-of-magnitude gap concentrated in cache writes rather than cache reads, is the part that should change how you think about session hygiene: minimizing unnecessary cache invalidation matters far more on Claude Code than the raw preamble-size gap alone would suggest.

Claude Code's subagent architecture is one of its strongest features and one of its least obvious cost multipliers at the same time. When a task fans out into subagents, each one opens its own model context, which means each one pays the full preamble tax independently rather than sharing a single cached copy across the parent and its children.

The same mid-2026 measurement that surfaced the base gap found a task running at roughly 121,000 tokens as a single agent reaching roughly 513,000 tokens total once subagent fan-out was counted, a better-than-4x multiplier stacked directly on top of the per-call preamble gap already documented above. That compounding is the mechanism, not a one-off anomaly: every subagent Claude Code spawns is, from a token-accounting perspective, a fresh session that re-pays the system prompt, the 27-tool schema, and the reminder scaffolding from zero.

If your team leans on parallel subagents or Agent Teams for multi-file refactors, this is the multiplier to model before you estimate monthly spend, not after you get the bill. Our guide to fixing context bloat in long-running agents covers the adjacent failure mode, where accumulated tool output rather than fan-out is what blows the context budget, and the two problems compound when they show up in the same session.

None of this matters much for a single developer running a handful of sessions a day. It matters a great deal at team scale, where session count, not per-call sophistication, is what drives the bill.

Take the cache-write delta from above (roughly $0.20 per fresh Claude Code session versus roughly $0.004 for OpenCode, using a mid-2026 Sonnet-tier cache-write rate as the illustrative baseline) and scale it. A 50-engineer team running 40 fresh sessions a day per engineer, a plausible cadence once you count branch switches, context edits that invalidate the cache prefix, and normal session churn, works out to roughly 2,000 fresh sessions a day. At the measured delta, that's on the order of $390 a day, or somewhere near $8,500 a month, attributable purely to preamble cache-write overhead, before counting the base per-turn gap or any subagent fan-out multiplier on top of it. That's an illustrative extrapolation from the measured token deltas, not an observed client invoice, and your real number depends on your actual session cadence, model tier, and how aggressively your team lets caches go cold. But it's the right shape of math to run before signing a team-wide tool decision, and it's the kind of number that's invisible until someone puts a logging proxy in front of the harness.

Tool breadth and injected safety scaffolding aren't waste, they're a design choice, and for some workloads they're the right one. Claude Code's larger tool surface means fewer round trips for tasks that would otherwise require composing several primitive file and shell operations, and its reminder injections exist to keep long, complex sessions from drifting off task, misformatting output, or bypassing a guardrail the model would otherwise forget mid-session. If you're running long agentic sessions on large, unfamiliar codebases where reliability matters more than per-call cost, the extra tokens are buying something real.

OpenCode's leaner preamble is the better trade for short, well-scoped edits, high-frequency automation where session count dominates cost, or workflows where you've already built your own tool layer and don't need 27 built-ins you'll mostly ignore. Sandboxing and isolation strategy factors into this tradeoff too: if you're already running agents in constrained environments, our guide to sandboxing coding agents locally without a VM covers a complementary layer of overhead and risk management that's worth weighing alongside raw token cost.

Published benchmarks, including the numbers in this post, describe someone else's configuration on someone else's day. Your actual overhead includes whatever MCP servers, custom tools, and project-level instructions (CLAUDE.md files and equivalents) you've layered on top of the base harness, and those additions don't show up in anyone's public measurement.

The method that produced the numbers above generalizes to your own setup:

If you're indexing a large codebase and comparing retrieval strategies as part of the same cost audit, semantic code search cutting agent token usage by roughly 40% at equal retrieval quality targets a different line item (retrieval, not preamble) but compounds with the mitigations below.

A few concrete levers, roughly in order of effort:

The category-level lesson holds regardless of which tool wins your team's evaluation: the fixed cost a coding agent pays before it reads your prompt is not a rounding error once you're running it across a team, and it is measurable with nothing more exotic than a proxy and a stopwatch. For the wider set of decisions that go into building and governing an AI-assisted engineering stack, our AI development tools pillar covers the surrounding tradeoffs beyond token accounting alone.