Is Claude Code's token overhead wasted?

Not purely. Most of the 33,000 tokens — about 24,000 — is tool-definition schemas for 27 built-in tools, including the background-agent and subagent-orchestration suite. If you use agent teams, that's capability you are paying for; if you never do, it's payload you can't easily strip. The high baseline is also partly offset by behavior: Claude Code batches parallel tool calls, making fewer total requests, and whole-task cost is roughly baseline times request count plus conversation growth — so a large baseline with few requests can land near a small baseline with many. The honest read is that a big baseline buys a capable, heavily-scaffolded agent; it becomes waste only when you carry tools, MCP servers, and instruction files you never use.

Claude Code's 33,000-token startup tax — where it goes, whether it's waste, and what to cut

Q: How many tokens does Claude Code use before you send a message?

In a July 2026 logging-proxy measurement on a fresh config with no MCP servers or instruction files, Claude Code sent about 33,000 tokens on the first turn — before the user typed anything. That splits into roughly 6,500 tokens of system prompt, about 24,000 tokens of tool-definition schemas (27 built-in tools), and around 2,000 tokens of scaffolding and reminder blocks. A leaner agent (OpenCode) sent about 7,000 tokens for the same cold start, so Claude Code's baseline was about 4.7x larger. With MCP servers and CLAUDE.md files loaded — a normal working setup — the same measurement put the real-world starting point at 75,000-85,000 tokens, over 40% of a 200k context window consumed before your prompt.

Q: If the overhead is cached, why does it matter?

Prompt caching means a byte-stable prefix is written to cache once (billed at 1.25x-2x the input rate) and read on later turns at about 0.1x — so a big-but-stable prefix is cheap in steady state. The catch is that Claude Code's prefix is not byte-stable: the measurement found the harness emitting several distinct request shapes per session, with the system bytes varying between requests, which forces the cache to be rewritten mid-session instead of just read. Claude Code wrote up to 54x more cache-creation tokens than the leaner agent (one file task: 53,839 vs 1,003), and every rewrite bills at the write premium, not the read discount. So the overhead that leaks money isn't the 33,000-token baseline itself — it's how often that baseline has to be re-cached.

Q: How do I reduce Claude Code's token overhead?

The built-in system prompt and core tool schemas are fixed — you can't trim those. What you control is everything stacked on top. Keep CLAUDE.md and memory files lean, since they load in full into every request with no deferral — that's the highest-certainty cut. Disconnect MCP servers a project doesn't use: by default Claude Code defers MCP tool schemas (it loads names and fetches schemas on demand), so MCP inflates the baseline less than the raw tool block, but tool names still ship and disconnecting removes them entirely — a permission deny rule does not, since it gates execution, not context. Use the /context command to see the live breakdown of what's filling your window. And route heavy fan-out through subagents deliberately, not reflexively — each subagent carries its own baseline, so spawning them multiplies the overhead.

Q: Does Claude Code really use 4.7x more tokens than OpenCode?

That figure is one measurement, not a law. It came from a single July 2026 test on one machine, with a pinned model and a local gateway in the request path, comparing cold-start baselines on fresh configs. The ~33,000-vs-7,000 split (4.7x) is the startup overhead specifically, and the char-level breakdown is directly measured, so the shape is trustworthy. But agent harness prompts change frequently, the sample is small, and whole-task token use depends on request count and batching, not just the baseline. Treat 4.7x as a well-sourced snapshot of the startup tax, not a permanent per-task multiplier.

Open a fresh Claude Code session, type nothing, and the first request to the model is already about 33,000 tokens long. That number comes from a July 2026 measurement that put a logging proxy between the agent and the API and read off exactly what gets sent before the user’s first word. The same setup measured a leaner coding agent, OpenCode, at roughly 7,000 tokens for the identical cold start — so Claude Code’s baseline is about 4.7x larger. The headline framing was “Claude Code sends 4.7x more tokens before reading your prompt,” and it landed near the top of Hacker News.

It’s a striking number, and the easy conclusion is “Claude Code is bloated.” That conclusion is half right and points at the wrong thing. This page walks the 33,000 tokens down to where each one goes, then explains the part the hot take skips: why the raw baseline is not what actually costs you, and what does. Sources are at the end.

The 30-second version

The baseline is real. ~33,000 tokens on Claude Code’s first turn vs ~7,000 for OpenCode, measured on fresh configs with no MCP or instruction files. That’s the cold-start tax, before you type.
Tool schemas dominate. About 24,000 of the 33,000 is tool-definition JSON for 27 built-in tools — the coding core plus the background-agent and orchestration suite. System prompt is ~6,500; scaffolding ~2,000.
You don’t pay it at full price every turn. A stable prefix is cached: written once at 1.25x-2x, then read at ~0.1x. In steady state, a big-but-stable prefix is cheap.
The real leak is cache churn. Claude Code’s prefix isn’t byte-stable, so the cache gets rewritten mid-session — up to 54x more cache-creation tokens than the lean agent in one test. Rewrites bill at the write premium, not the read discount.
Real-world start is 75,000-85,000. Add MCP servers and CLAUDE.md files — a normal setup — and you begin every request having spent over 40% of a 200k window.
High overhead isn’t pure waste. It buys a capable agent, and parallel-call batching offsets some of it. It becomes waste when you carry tools, servers, and files you never use.

Where the 33,000 tokens go

The measurement broke the cold-start payload into three parts. Here is each side by side, on a fresh config with no MCP servers and no instruction files loaded:

Component	Claude Code	OpenCode
System prompt	~27,300 chars (~6,500 tokens)	~9,300 chars (~2,000 tokens)
Tool-definition schemas	~99,800 chars (~24,000 tokens)	~20,900 chars (~4,800 tokens)
Scaffolding / reminder blocks	~8,000 chars (~2,000 tokens)	none
Total cold start	~33,000 tokens	~7,000 tokens
Built-in tools	27	10

The single biggest line is not the system prompt — it’s the tool schemas, at roughly 24,000 tokens, nearly three-quarters of the whole baseline. Claude Code ships 27 tools where OpenCode ships 10 classic coding tools, and every one of those definitions — name, description, and full JSON input schema — is serialized into the request on every turn so the model knows what it can call.

Those extra 17 tools aren’t padding. They’re the background-agent, subagent, and orchestration machinery that make Claude Code an agent-team platform rather than a single-threaded coding assistant. Which is the first honest tension in the number: if you use agent teams, the 24,000 tokens is the capability you came for; if you never do, it’s payload you can’t easily remove.

The catch that caching hides

Here’s where the “33,000 tokens per turn” framing misleads. You do not pay 33,000 tokens at the full input rate on every request. Claude’s API caches stable prefixes: the tools block and system block render first, in a fixed order, and if their bytes don’t change, they’re written to cache once and then read on subsequent turns at about one-tenth the input price. A cache write costs a small premium — 1.25x the input rate for the 5-minute cache, 2x for the 1-hour cache — but that premium is paid once and amortized across every later turn that reads it. For a genuinely stable 33,000-token prefix, the steady-state cost is small.

That’s the theory. The measurement found Claude Code doesn’t get the full benefit of it. The proxy logged the harness emitting several distinct request shapes within a single session, with the system bytes varying between requests. Because caching is a strict prefix match — one byte different anywhere in the prefix and everything after it misses — a prefix that changes shape mid-session forces the cache to be rewritten instead of read. The lean agent kept its prefixes byte-identical and rode the cheap read path; Claude Code churned.

The bill shows it. Across the comparison, Claude Code wrote up to 54x more cache-creation tokens than OpenCode. On one file-summarization task, Claude Code logged 53,839 cache-creation tokens against OpenCode’s 1,003. Cache-creation tokens are the ones billed at the 1.25x-2x write premium — so the money that actually leaks isn’t the 33,000-token baseline sitting cheaply in cache, it’s how often that baseline has to be re-cached. The overhead that costs you is the churn, not the size.

This is the concrete mechanism behind a pattern developers already feel: Claude Code burning through a token-metered quota faster than a leaner tool on the same work. We covered the quota side of that in the Codex vs Claude Code usage-limits breakdown — the cache-rewrite behavior here is one of the reasons the same-shaped wall arrives sooner.

In the real world it’s 75,000-85,000

The 33,000-token figure is the clean-room number — fresh config, no MCP, no memory files. Almost nobody runs Claude Code that way. Add the things a normal developer loads and the same measurement put the real starting point at 75,000 to 85,000 tokens before the first prompt, which on a 200k context window is over 40% consumed on every single request.

Two additions drive the jump, and they behave differently:

Instruction files load in full, every turn. CLAUDE.md — global, project, and local — plus auto-memory files are read into the context of every single request. A sprawling CLAUDE.md is overhead you pay on each turn, re-sent whether or not it’s relevant, which is exactly why CLAUDE.md token mistakes and CLAUDE.md size and performance are worth taking seriously; the file feels free to edit and isn’t.
MCP servers are more nuanced than “every schema, every request.” By default, Claude Code loads only MCP tool names at startup and fetches the full schemas on demand — a tool-search deferral that deliberately keeps a big server list from ballooning the baseline. But the names still add up across many servers, and when tool search decides to load schemas upfront (its default when they fit the budget) or you turn deferral off, MCP definitions land back in the baseline in force. So MCP is a real contributor to the 75-85k figure — just a smarter-handled one than the raw tool block, and the mitigation is already shipped.

It also compounds through subagents. Each subagent spins up with its own fresh context and its own baseline — a leaner system prompt than the main session’s, but a reloaded CLAUDE.md and tool set on top — so fanning work out multiplies the fixed cost. The measurement caught a task whose direct work was 121,000 tokens ballooning to 513,000 tokens once it spread across two subagents — roughly a 4x multiplier, most of it repeated baselines. Whether that trade is worth it is the whole subject of are Claude Code agent teams worth it; the token math here is the cost side of that ledger.

Is any of it actually waste?

The satisfying answer would be “yes, 33,000 tokens of bloat.” The honest answer is more mixed.

Against the “pure waste” read: whole-task token use is roughly baseline × request count + conversation growth, and Claude Code makes fewer requests than a serial agent because it batches parallel tool calls into single turns. A large baseline with few requests can land close to a small baseline with many requests — so the per-request 4.7x doesn’t translate to a 4.7x whole-task bill. The Hacker News discussion of the measurement made exactly this point, and it’s correct: the startup tax and the total-session cost are different numbers.

For the “waste” read: none of that helps if you’re carrying capability you don’t use. The 24,000 tokens of tool schemas assume you might orchestrate subagents; a stack of MCP servers assumes you’ll call all of them; a 400-line CLAUDE.md assumes every line earns its place on every turn. When those assumptions are false, the overhead is real waste — you’re paying write premiums and window space to cache tools and instructions that never fire.

So the fair verdict: the baseline buys a genuinely capable, heavily-scaffolded agent, and it turns into waste at the margin you personally don’t use. The fix isn’t to resent the 33,000 tokens. It’s to stop stacking unused weight on top of them.

What you can actually cut

The built-in system prompt and the 27 core tool schemas are fixed — you can’t trim those, and chasing them isn’t worth your time. Everything that turns 33k into 85k, though, is yours to control:

Keep CLAUDE.md lean. This is the highest-certainty cut, because memory files load in full on every request — there’s no deferral. Shorter, higher-signal files cost fewer tokens per turn and, separately, follow instructions better; the over-engineering rules and token-mistake guide both quantify the win.
Disconnect unused MCP servers per project. Deferral caps how much MCP inflates the baseline, but it doesn’t zero it — tool names still ship and schemas still get fetched on demand. Disconnecting a server a project doesn’t need removes all of that, where a permission deny rule doesn’t (it gates execution, not context). See the best MCP servers for which ones earn their keep.
Inspect with /context. Claude Code exposes a live breakdown of what’s filling your window — system prompt, tools, MCP tools, memory files, and messages. Run it when a session feels heavy; it turns the abstract “overhead” into a specific line item you can act on. See context management for the wider workflow.
Spawn subagents on purpose. Because each one carries a full baseline, fan-out is a real cost, not a free parallelism win. Delegate when the work genuinely splits; don’t reflexively.

The real lesson

“Claude Code sends 33,000 tokens before your first word” is true, well-measured, and mostly not the problem people think it is. The baseline is large because the agent is capable, and caching is supposed to make a large-but-stable baseline cheap. What the measurement actually exposed is narrower and more useful: Claude Code’s prefix churns, so it pays cache writes where a byte-stable agent pays cache reads — and it invites you to stack MCP servers, instruction files, and subagents on top, each of which is a genuine, cuttable cost. The number to watch isn’t 33,000. It’s how much you’ve added to it, and how often it’s being re-cached.

Companion reading

Codex vs Claude Code usage limits — why the higher token burn hits the same-shaped wall sooner
Claude Code usage limits, explained — the 5-hour window, weekly caps, and how to watch your burn
Claude Code context management — the /context command and the wider workflow for a crowded window
Are Claude Code agent teams worth it — the capability the 24,000 tokens of tool schemas pay for
CLAUDE.md token mistakes — the instruction-file overhead you pay on every request

Sources

FAQ

How many tokens does Claude Code use before you send a message? About 33,000 on a fresh config with no MCP or instruction files, per a July 2026 logging-proxy measurement: ~6,500 for the system prompt, ~24,000 for 27 tool-definition schemas, and ~2,000 for scaffolding. A leaner agent (OpenCode) sent ~7,000 for the same cold start — a 4.7x gap. With MCP servers and CLAUDE.md loaded, the real-world start is 75,000-85,000 tokens, over 40% of a 200k window.

If the overhead is cached, why does it matter? A byte-stable prefix is written to cache once (at 1.25x-2x the input rate) and read later at ~0.1x, so a stable baseline is cheap in steady state. But Claude Code’s prefix isn’t byte-stable — the harness emits several request shapes per session, forcing mid-session cache rewrites. It wrote up to 54x more cache-creation tokens than the lean agent (one task: 53,839 vs 1,003), each billed at the write premium. The leak is the churn, not the size.

Is the 33,000-token overhead wasted? Not purely. Most of it (~24,000 tokens) is schemas for 27 tools, including the subagent-orchestration suite — capability if you use agent teams, dead weight if you don’t. Batching parallel tool calls also offsets the high baseline, since whole-task cost is roughly baseline × requests + growth. It’s waste only at the margin you don’t use: unused MCP servers, tools, and instruction files.

How do I reduce Claude Code’s token overhead? You can’t trim the built-in system prompt or core tools, but you control what’s stacked on top. Keep CLAUDE.md and memory files lean — they load in full on every request with no deferral, so that’s the surest cut. Disconnect MCP servers a project doesn’t use: Claude Code defers MCP schemas by default (names upfront, schemas on demand), so MCP inflates the baseline less than the raw tool block, but disconnecting still removes the names a permission deny would leave in place. Run /context to see the live breakdown, and spawn subagents deliberately — each carries its own baseline.

Does Claude Code really use 4.7x more tokens than OpenCode? That’s one July 2026 measurement on a single machine with a pinned model and a local gateway in the path — the ~33,000-vs-7,000 cold-start split. The char-level breakdown is directly measured, so the shape is trustworthy, but harness prompts change often, the sample is small, and whole-task use depends on request count and batching, not just the baseline. Treat 4.7x as a well-sourced snapshot of the startup tax, not a permanent per-task multiplier.