The scaffolding tax: why Claude Code spends 33,000 tokens before it reads your prompt

When you type a request into a coding agent, you probably picture the model reading your words and going to work. That is not what happens. Before your prompt reaches the model, the harness around it — the wrapper program that turns "an LLM" into "an agent that can edit files and run commands" — has already spent thousands of tokens setting the stage. A benchmark published by Systima on 12 July put a number on it: Claude Code sends roughly 33,000 tokens of scaffolding before your prompt, and OpenCode, running the same underlying model, sends about 7,000.¹ I want to walk through what that scaffolding actually is, why the gap exists, and why the more interesting number in the study is not 33,000 but 54.

What "scaffolding" means here. A coding agent is not just a model. It is a model plus a program that tells the model what tools exist, how to call them, what conventions to follow, what the project looks like, and how to behave when things go wrong. All of that instruction is text, and all of that text has to be tokenised and sent to the model on every request. In Claude Code's case, Systima measured roughly 24,000 tokens of tool schemas alone — the machine-readable descriptions of every action the agent can take, such as "edit this file", "run this shell command", "spawn a subagent".¹ The rest is system prompt, routing logic, and formatting rules. None of it is your code. None of it is your question. It is the agent explaining itself to itself before it starts.

Why the number is not, on its own, alarming. Claude Code's context window is 200,000 tokens. Spending 33,000 on scaffolding uses about 16.5% of it before anyone types anything.¹ That is real, but a well-described tool surface is what lets the agent reliably do things. OpenCode's 7,000-token overhead reflects a leaner set of tools — Systima's summary notes it exposes roughly 10 tools versus Claude Code's 27.¹ Fewer tools, less text to describe them, less capability. The trade is genuine. If you want an agent that can create cron jobs, manage git worktrees, dispatch push notifications, and coordinate subagents, something has to tell the model those tools exist, and that something is tokens.

Where the real money goes

The headline number gets attention. The finding that matters is buried further down: Claude Code produces up to 54 times more cache-write tokens than a stable-prefix setup like OpenCode.¹ To see why that sentence is worth staring at, you need to know what prefix caching is.

Prefix caching, plainly. When a model processes a prompt, it builds an internal representation of every token — the intermediate math the transformer needs to keep going. That work is expensive. If the next request starts with exactly the same text, the provider can reuse the work it already did on the shared prefix and only compute the new tail. Anthropic exposes this as prompt caching, and the pricing gap is stark: on Sonnet's tier, a cached read costs $0.30 per million tokens; writing to the cache in the first place costs $3.75 per million — 12.5x more expensive than a read, and roughly 25% more expensive than a normal uncached input token.²

That pricing is the whole game. Cache hits are the reward. Cache writes are the tax you pay to earn future hits. If your scaffolding is stable, you write the cache once and read it back for the rest of the session — cheap. If your scaffolding changes even slightly between requests, the cache cannot match, and you pay the write price over and over.

Why Claude Code writes the cache so often. The 33,000-token scaffolding is not literally different every call, but Systima found enough dynamic content sprinkled through it, the kind of small, moving parts that agent harnesses tend to grow, to keep the cache from stabilising.¹ The result is that a lot of Claude Code's context, which looks reusable, gets re-billed as cache writes instead of cache reads. That is where the 54x comes from. It is not that Claude Code sends 54x more text; it is that 54x more of the text it sends is being paid for at the write rate rather than the read rate. OpenCode's simpler, byte-stable prompt lets the cache do the job it was designed for.

The mental model I would hold: the token count tells you how much you are sending; the cache stability tells you how much you are actually paying for. Two agents with the same token count can differ by an order of magnitude on the bill.

The multiplier nobody sees until they get invoiced

There is a third effect, distinct from the first two. Modern coding agents delegate: a parent agent, faced with a large task, spawns child agents ("subagents") to work on parts of it in parallel. Systima measured that subagent delegation multiplies total token consumption by about 4.2x in Claude Code.¹ The reason is mechanical — every child agent boots up with its own copy of the full scaffolding. If the parent's context costs 33,000 tokens to set up and it spawns four children, you are now paying that setup cost five times, once for the parent and once per child, before any of them have done any work.

When the trade is worth it. Subagent fanout is not wrong; parallelism buys wall-clock speed, and for tasks that genuinely decompose, spending 4x the tokens to finish in a quarter of the time can be the right call. But it compounds the scaffolding-tax problem: every additional agent re-pays the full overhead. On a lean harness the multiplier still applies, but the base it multiplies is much smaller.

What to actually take from this

Three things, in order of how much they should change your thinking.

The cache-stability finding is the important one. Watch cache-write versus cache-read ratios in your usage dashboards, not just total tokens. A harness that sends more text but caches cleanly can be cheaper than one that sends less text but keeps invalidating its cache.

The 33k number is a design choice, not a defect. It is the price of Claude Code's tool surface. Whether that surface is worth 16.5% of your context window is a question about what you are building, not a bug to be outraged about.

The subagent multiplier is the one to model before you turn it on. Parallel agents are a feature; they are also a feature that re-pays the scaffolding cost per child. If you are running Claude Code with heavy fanout on large projects, that is where your bill is coming from.

The Systima study is worth reading in full,¹ not because coding-agent economics will look the same in six months, Anthropic can and probably will trim Claude Code's overhead in future releases, but because the shape of the analysis will keep applying. Every agent harness sits on top of a model, and every harness makes choices about how much to say to the model before you do. Those choices are what you are buying, and now, thanks to practitioners reading their own usage meters, they are also something you can measure.

Footnotes and links

Further reading

• Developers Digest, "Claude Code Sends 33k Tokens Before Your Prompt": https://www.developersdigest.tech/blog/claude-code-token-overhead-opencode-comparison
• HyperAI, "Claude Code Token Usage Significantly Exceeds OpenCode in Testing": https://hyper.ai/en/stories/af30ea7b31515aacf9ac367073567efe