AI coding agents are burning tens of thousands of tokens before they even read your prompt
Before an AI coding agent reads a single word you type, it has already spent thousands of tokens introducing itself: system prompts, tool schemas, scaffolding reminders. A recent independent comparison of two popular agent harnesses, Claude Code and OpenCode, measured this overhead directly using a logging proxy that captured the exact JSON payloads sent to the model API. The gap was large enough to change how anyone running these tools at scale should think about cost.
On a first-turn baseline task on Claude Sonnet 4.5, Claude Code sent roughly 32,800 tokens before the user's actual prompt was processed. OpenCode sent about 6,900 tokens for the same task — a 4.7x difference. The gap narrows to 3.3x on newer models but doesn't close. This overhead is invisible in normal use: you type a prompt, get a response, and never see the payload that got sent underneath it. But it's billed like everything else, and it compounds in ways that matter once you move past toy examples.
Where the tokens actually go
The overhead breaks into three measurable components. System prompts account for the smallest share but still a real one: Claude Code's system prompt runs 27,344 characters (roughly 6,500 tokens), versus OpenCode's 9,324 characters (~2,000 tokens). Tool schemas are the larger cost — Claude Code ships 27 tool definitions spanning about 99,778 characters (~24,000 tokens), while OpenCode's leaner toolset of 10 tools comes in at 20,856 characters (~4,800 tokens). The remainder is scaffolding: Claude Code injects reminder blocks, agent catalogues, and context framing ahead of the user's actual message; OpenCode adds none of this by default.
None of this is waste in the sense of being useless — more tools and richer scaffolding generally mean the agent can do more without asking clarifying questions. It's a real design tradeoff between capability-per-request and cost-per-request, and it's one most users never get to see, let alone choose.
The gap gets worse with realistic configuration
The baseline numbers understate what production setups actually cost. Add a typical 72KB project instruction file (the kind of CLAUDE.md or AGENTS.md file most serious codebases now maintain) and both harnesses pick up roughly 20,000 additional tokens per request — this part is configuration-driven, not harness-driven, so it hits both tools equally. Layer in five MCP (Model Context Protocol) servers, a common setup for teams wiring in Slack, Jira, databases, or internal APIs, and each server adds 4,900 to 6,967 tokens per request just to advertise its available tools.
Stack all of this together and a realistic production configuration reaches 75,000 to 85,000 tokens deep before the user has typed a single word of their actual request. On a 200,000-token context window, that's over 40% of the available space consumed by scaffolding before any code gets written or read.
Caching behavior is where the real cost divergence happens
The more consequential difference isn't the baseline token count — it's what happens to that overhead across a session. OpenCode maintains a byte-identical request prefix across turns, which means prompt caching works close to ideally: the same tokens get reused from cache turn after turn with minimal rewrites.
Claude Code's scaffolding, by contrast, gets rewritten mid-session — new reminder blocks, updated context, refreshed tool state — which forces the cache to be invalidated and rebuilt repeatedly. The measured cache-write volume for Claude Code ranged from 5.9x to 54x OpenCode's, depending on how “warm” the cache was at measurement time. Cache writes aren't free: they bill at a 1.25x premium over the base input rate for a standard 5-minute TTL. A harness that's constantly rewriting its own cache is paying that premium far more often than one that isn't.
Subagents multiply the problem, not just add to it
The starkest number in the comparison involves delegation. A task that cost 121,000 cumulative tokens when run directly cost 513,000 tokens when the same work was fanned out to two subagents — a 4.2x increase for what should, in principle, be the same total amount of work split up. Each subagent re-pays the full baseline overhead (system prompt, tool schemas, scaffolding) independently; delegation doesn't share that cost, it multiplies it by the number of agents spawned.
This matters directly for how teams should architect agentic workflows. Fanning a task out to subagents is often framed as a pure parallelism win — more agents, less wall-clock time. The token accounting tells a different story: it's a real cost tradeoff, and for small or medium tasks, the overhead multiplication can outweigh whatever time you save.
What to actually do with this
Interestingly, on complex multi-step tasks the harnesses converge: Claude Code used 121,000 cumulative tokens across 3 requests (aggressive tool-call batching), while OpenCode used 132,000 tokens across 9 serialized requests. For genuinely complex work, the baseline overhead gap matters less because it's amortized across more actual work per request.
The practical takeaways: audit your CLAUDE.md/AGENTS.md file size — that 20,000-token tax hits every single request regardless of harness. Be deliberate about how many MCP servers you keep active; each one is a fixed per-request cost whether or not you use it in a given turn. And treat subagent fan-out as a cost decision, not just a speed decision — reserve it for tasks large enough that the 4x overhead multiplier is worth paying for the parallelism.