Claude Code's Hidden Token Tax: 4.7x More Before You Start
The Systima analysis from July 2026 pinned both Claude Code and OpenCode to the same model — Claude Sonnet 4.5 — and ran identical tasks on identical hardware. Before either tool reads a single word of user input, Claude Code ships roughly 32,800 tokens across the wire. OpenCode ships 6,900. That's the 4.7× headline from the Systima benchmarks reported by WebProNews. But the same run showed Claude Code finishing a multi-step write-run-test-fix loop in three model requests by batching parallel tool calls — OpenCode needed nine turns, one tool per cycle. The bigger baseline, paid fewer times, sometimes wins. Token floors are not the whole story.
This is the framing the headline misses. The 4.7× number is the empty-desk weight of each tool — what gets shipped before the user types. The cumulative cost on real work depends on how the tool spends its turns. Both numbers matter. Treating one as the verdict is what gets the math wrong.
What the floor actually contains
Strip Claude Code down to its system prompt and tool schemas, and the 32,800 number splits into two parts. Claude Code declares 27 tools — including orchestration primitives, background agent launching, worktree management, and notification plumbing. OpenCode declares 10 core coding tools. That delta alone explains a chunk of the weight.
But the system prompt itself is doing real work. Claude Code's prompt weighs 6,500 tokens; OpenCode's comes in at 2,000. The remaining delta is harness: Claude Code ships richer agent guidance, safety rails, and orchestration instructions inline because it has more surface to coordinate. OpenCode moves that into the model's hands at runtime — fewer tokens, more inference per call.

The honest framing: Claude Code's floor is high because it's a heavier tool, not because it's wasteful. If you need 27 tools, the cost of declaring them is the cost of having them.
Real workloads stack on top
The empty-desk weight is just the start. Both tools add tokens per request based on what's attached.
A 72-kilobyte AGENTS.md from a production repo — the conventions file your team maintains so AI agents understand how to write code in your codebase — adds more than 20,000 tokens per request for both. Five modest Model Context Protocol servers tack on another 5,000 to 7,000. A fresh workspace now sits at 75,000 to 85,000 tokens before any user input. Builder.io reported seven active servers consuming 25% of a 200,000-token window before the prompt arrived.

The base-model delta between Claude Code and OpenCode shrinks in percentage terms once AGENTS.md and MCP servers land. A 25,900-token floor difference against a 75,000-token total is closer to 35% than 470%. The headline ratio lives in the empty workspace; the production ratio lives somewhere else.
11 production screens. Login, database, payments — all wired.
The SaaS Dashboard Kit ships everything already connected. Nothing to set up. Live demo at saas.otf-kit.dev.
Where Claude Code genuinely wins
On a single multi-step write-run-test-fix loop, OpenCode's lower floor gets eaten by its serialization. Claude Code parallel-batched the tool calls — three requests totaling about 121,000 cumulative input tokens. OpenCode issued nine turns, one tool per cycle, and landed around 132,000.

That's a 9% deficit for the lighter tool on a loop where you'd expect it to dominate. The reason is turn-count amortization. Claude Code's high baseline gets divided across fewer model calls. The 32,800-token floor paid three times is 98,400 tokens of bootstrap. The 6,900-token floor paid nine times is 62,100. Harness overhead per turn matters less when you batch.
This is a real engineering win, not a marketing claim. The Systima researchers flagged it as the surprise of the run.
Where the floor reasserts itself
Fan the task to two subagents and the math flips. Claude Code hit 513,000 tokens. Each subagent carried its own bootstrap payload — the 32,800-token floor gets paid twice, plus coordination tokens. OpenCode's flatter toolset amortizes better across branches. The same baseline that wins on a single loop loses on fan-out, because every parallel branch repays the floor independently.
If you're running single-session agent work, Claude Code's parallel batching is a real tailwind. If you're running subagent trees or long orchestration graphs, the lighter tool pulls ahead. The right answer depends on the shape of the work, not on which tool's marketing page you read.
How to use OpenCode today
OpenCode is MIT-licensed and runs against any model provider that speaks the standard API. The 4.7× headline is reproducible against Claude Sonnet 4.5 specifically; other models will show different ratios.
Install from the project's published channel:
# OpenCode ships via npm, go install, and a curl-based installer.
# The README lists the canonical command for your platform.
opencode --version # verifyPoint at Claude Sonnet 4.5 through OpenRouter. The provider block accepts a base URL, an API key, and a model id — pin them and OpenCode routes every request through it:
export OPENROUTER_API_KEY="sk-or-..."
# OpenCode's config takes a provider block with baseURL + model + key.
# The current schema is in the project's docs.
opencodeTrim your context budget before you ship:
# count what AGENTS.md costs you today
wc -c AGENTS.md # 72 KB ≈ 20k tokens per request
# audit your active MCP servers
# (the CLI exposes an mcp list command — see the project's docs)The AGENTS.md discipline matters more than the tool choice. Every kilobyte in that file is paid on every request. The Systima data shows a 72 KB conventions file adding 20,000+ tokens across both tools — a five-figure surcharge before your prompt arrives.
How to keep Claude Code's parallel-batching wins
If you're staying on Claude Code, the parallel-batching advantage is real and worth protecting.
# audit your active MCP servers
# (the Claude Code CLI exposes an mcp subcommand — list, add, remove)
claude mcp list
# drop the ones you don't actively use
claude mcp remove github-actions
claude mcp remove sentrySeven active servers at Builder.io ate 25% of a 200k window before any prompt. Every disabled server is 1,000 to 2,000 tokens you stop paying per request, every turn, for the rest of the session.
Keep AGENTS.md lean. The model's behavior is governed by what it reads, not by how much prose surrounds the rules:
# target: 4 KB — conventions only, no prose
## Build: pnpm install && pnpm dev
## Test: pnpm test --run
## Style: no default exports, 2-space indentA 4 KB conventions file replaces a 72 KB one and costs you ~1,100 tokens instead of ~20,000. The model still reads it on every request.
Subagent fan-out is where Claude Code's floor compounds worst. If your workflow needs parallelism, run a single coordinated agent and let Claude Code's parallel batching work within that session — it does not work across forked subagents, and each fork repays the 32,800-token baseline independently.
The part that doesn't change when the model does
The token economy is a model-layer problem. Whether you pay 32,800 or 6,900 tokens per turn, the result still has to ship to a user — and that user's surface is web, iOS, Android, and the inevitable fourth platform your roadmap has not committed to yet.
Cross-platform UI consistency is a separate problem, and it's the one your users actually feel. The same component should look and behave the same on every platform from one API — so that switching your model, your harness, or your token budget does not force a rewrite of every screen. OTF sits underneath that decision. Pick the tool that pays the lowest cost per task — Claude Code when parallel batching wins, OpenCode when you fan out, whichever benchmark the next quarter crowns — and the UI stays put.
The token tax is a variable you can tune. The component your user taps is not. Build the variable to be swappable; build the surface to be stable.
Ship the product, not the setup.
- 11 production screens — auth, billing, team, analytics, settings
- Real database, payments, and login — all wired on day 1
- AI configs pre-tuned so your agent extends instead of regenerates