MP Marc Pope Let's Talk
The 33,000-Token Tax: What AI Coding Tools Cost Before They Read Your Prompt

The 33,000-Token Tax: What AI Coding Tools Cost Before They Read Your Prompt

A wire-level analysis of Claude Code reveals AI coding assistants burn 33,000 tokens on scaffolding before touching your prompt—a hidden infrastructure cost that compounds at team scale.

I've been building AI-augmented development workflows for the better part of this year, and something has been nagging at me: the token bills don't add up. You run a simple task—summarize a file, write a test—and the API usage report shows five times what you'd expect. For months I chalked it up to agent loop overhead and moved on. This week, a team at Systima published a wire-level analysis that finally put numbers to the suspicion, and the numbers are uncomfortable.

Their finding: when Claude Code receives a request, it sends approximately 33,000 tokens to the API before a single word of your prompt arrives. The equivalent measurement for OpenCode, the open-source alternative built on the same model, is roughly 7,000 tokens. That is a 4.7x gap in baseline overhead, all of it paid by you, all of it on every request, whether the task takes 30 seconds or three hours.

What Lives Inside Those 33,000 Tokens

The Systima team deployed a logging proxy between the tool harnesses and Anthropic's API endpoint—about 200 lines of Node—and captured exact JSON request payloads: system blocks, tool schemas, and usage metrics. What they found is architectural, not incidental.

Claude Code ships 27 tool descriptions with every cold request. OpenCode ships 10. The schemas for those 27 tools weigh roughly 99,778 characters—approximately 24,000 tokens—before the model sees a single instruction or line of code. OpenCode's 10-tool schema runs about 20,856 characters, or 4,800 tokens. The difference isn't a bug; it's a design decision. Claude Code's richer toolset (background agents, skill delegation, multi-step orchestration primitives) has to describe itself fully in each request.

The base system prompt adds another layer: Claude Code's instruction set measures roughly 6,500 tokens with no tools at all. OpenCode's base prompt is about 2,000 tokens. So even before you count tools, the scaffolding starts at three times the weight.

On a simple "reply with OK" task—deliberately chosen to isolate baseline overhead—Claude Code issued a 32,800-token request. OpenCode issued a 6,900-token request. Both got the same answer: "OK."

The Cache Instability Problem Is the Real Story

Token count is visible. Cache instability is not—and in production, it's the part that compounds into real money.

Anthropic's prompt cache charges a premium write rate for tokens being cached for the first time, then a fraction of that for cache hits on subsequent requests. The model is: pay once, read cheap. But this only works if your requests are byte-identical at the prefix. Any variation forces a cache re-write.

OpenCode maintained byte-identical request prefixes across all test sessions. In a file-summarization loop, it required only 1,003 cache write tokens for repeated runs. The infrastructure behaves predictably, which is what you want from infrastructure.

Claude Code produced three distinct request classes per session with varying system bytes. One multi-step task triggered what Systima logged as "53,839 cache tokens written...including one complete mid-task re-write." Cache write ratios ranged from 5.9x to 54x higher than OpenCode across equivalent tasks. That re-write isn't a fluke; it reflects how Claude Code dynamically adjusts its context as it decides which orchestration path to take.

I've operated caching layers in web infrastructure for long enough to know that inconsistent cache invalidation is usually an architectural signal, not a tuning problem. When the cache is warm, you're fine. When it's not—and with Claude Code it unpredictably isn't—you're paying full write rates every time.

Real Deployments Are Worse by an Order of Magnitude

The 33,000-token figure comes from a clean-room test: no MCP servers, no instruction files, factory configuration. Nobody actually runs AI coding tools that way.

Systima ran the same measurements on realistic configurations. The numbers expand fast:

  • A 72KB CLAUDE.md instruction file adds roughly 20,000 tokens per request to both tools equally.
  • Five MCP servers contribute 4,900 to 6,967 additional tokens, depending on the schemas involved.
  • Subagent delegation—Claude Code's feature for spawning background agents—multiplied one task from 121,000 tokens to 513,000 tokens due to bootstrap requirements for each subagent. That's a 4.2x cost multiplier for each level of nesting.

The "real working configuration" benchmark told the full story: OpenCode with 11 MCP servers required 90,817 cold-cache tokens before the user typed anything. Claude Code with 4 servers required approximately 75,000 tokens. Both are roughly 12x their respective baselines—instruction files and MCP overhead hit them equally hard—but Claude Code's relative advantage on raw baseline narrows only because both explode upward together.

The Quality Punchline

If the overhead bought better outcomes, this would be a different conversation. It doesn't.

Systima ran a ten-lane benchmark across both tools using independent verification. Both passed five of five test suites. Average metered costs: 268,000 tokens for Claude Code, 72,000 tokens for OpenCode—a 3.7x differential for identical verified correctness.

On complex write-run-test-fix loops where Claude Code's orchestration features should help most, the results flip negative. Claude Code initially appeared competitive on one task (121,000 vs. 132,000 tokens) through parallel tool batching, but re-tested on newer models it required twice as many requests and consumed 298,000 tokens against OpenCode's 133,000—a 2.2x blowout in the scenario where its architecture is supposedly optimized.

None of this means Claude Code is bad software. The orchestration layer it ships is genuinely powerful. But "powerful" and "efficient" are not synonyms, and in infrastructure, they never have been.

What This Means If You're Running a Team

I want to work through the numbers the way I'd work through server capacity planning, because that's how I think about it.

Assume a development team of 30 engineers. Each runs 15 substantive AI coding sessions per day. In a real configuration—CLAUDE.md, a few MCP servers—Claude Code's cold-cache baseline sits around 75,000 tokens. Call it 50,000 tokens average per task after cache effects. That's 22.5 million tokens per day in overhead alone, before any actual code gets analyzed or written.

At current API pricing for claude-sonnet-5, input tokens run roughly $3 per million. That's $67.50 per day—$24,000 per year—in scaffolding. Not output. Not reasoning. Just the cost of asking the tool to start listening.

OpenCode's lean architecture pushes that same team's overhead down by a factor of three to four. The savings don't go into worse outcomes; the quality numbers are the same.

The subagent issue concerns me more than the baseline. I've been building workflows that use Claude Code's delegation features because they're elegant—you describe a task and let the orchestrator break it up. What this analysis surfaces is that each level of delegation multiplies the bootstrapping cost independently. A three-level task that reads fine in a demo becomes a token catastrophe in production. That's a classic abstraction-cost problem: the overhead is invisible during development and only becomes visible at scale, by which point it's baked into the architecture.

What I'm Taking Away from This

The practical question is not "which tool is better" but "what are you actually paying for." If your team lives at the complex end—multi-agent orchestration, background tasks, parallel execution—Claude Code's features have real value and the premium may be worth it. But if most of your usage is single-turn: summarize this, write this test, explain this error—you are paying a 4x overhead for capabilities you're not using, and you'll never see it in a benchmark because benchmarks don't measure baseline waste.

The broader infrastructure lesson is one I keep relearning in different contexts: abstractions are never free, and the cost usually hides in the baseline. I've seen this with container orchestration, with API gateways, with message queues that do more than you need. Every layer of capability you add to a system shows up somewhere in the bill, whether you use the capability or not.

For anyone who has ever trimmed a Dockerfile layer, consolidated a cron job, or switched from an application load balancer to a simpler reverse proxy because the overhead wasn't worth the features—this is the same conversation, happening inside the AI tooling stack.

Systima released their proxy rig as open-source on GitHub—approximately 200 lines of Node—so you can run the measurement yourself against your own configuration. I intend to. There is nothing like plugging in the actual numbers from your own infrastructure to settle what a vendor's marketing deck cannot.

The full analysis is worth reading at Systima's blog, and the Hacker News thread that surfaced it on July 12 generated a useful technical discussion worth scanning if you're working through the architecture implications. The Gigazine coverage has a clean summary of the token breakdown if you want the short version first.

In the meantime, if your AI coding tool bills have been nagging at you, now you know where to look first: not at your prompts, but at the 33,000 tokens that precede them.

Back to Blog