Claude Code Token Overhead: My Headless Sprint Bill
When a sprint kicks off in AgentSpace, the leader agent breaks the work into pieces, then the workers spin up one by one. Anyone running a multi-agent system through a headless CLI knows this moment: before a worker makes its first move, there’s a beat where nothing shows up on screen — the system prompt, tool schemas, and agent catalog are loading before the actual work has even started. That beat isn’t free.
The problem is that this cost never shows up on the console, only at the end of the month on the invoice. I’ve never broken this cost down before now; I could feel that my headless agents running on Claude were burning some amount of “empty” tokens every sprint, but I wasn’t measuring it. Systima’s new “Claude Code token usage overhead” benchmark landed right on that blind spot.
The news: Claude Code burns 33k tokens before the prompt even arrives
Systima (systima.ai) compared Claude Code and OpenCode on the same model, on the same tasks, through a proxy that logged the traffic in between. For a single one-line reply, Claude Code sent roughly 33,000 tokens of system prompt, tool schema, and injected scaffolding before the user’s prompt had even arrived; OpenCode spent about 7,000 tokens on the same job. That gap, measured on Sonnet 4.5, shrank to roughly 3.3x on Claude Fable 5, because Claude Code ships a smaller system prompt to the newer models.
As the source puts it: “A 33k-token baseline means every turn starts a sixth of the way into a 200k window before any code enters the conversation.” In the same benchmark, splitting a single task into two sub-agents pushed total cost from 121,000 to 513,000 tokens — a 4.2x jump. The one exception: on a multi-step task, Claude Code batched its tool calls into a single request and actually came out ahead of OpenCode overall.
What this means for us
You pay the floor, but you never amortize it
Systima’s 33k/7k gap was essentially measured in a long, multi-turn conversation scenario: the system prompt gets written once and read cheaply from cache on every following turn. AgentSpace’s workers don’t work that way. Every sprint opens a fresh headless call, does the task, and shuts the agent down. So that 33k-token floor doesn’t spread across ten turns and get cheaper — every single task chunk a worker takes on pays that floor from scratch, at full price.
That’s the sharpest part of the news for me: in our architecture, overhead doesn’t amortize, it accumulates. However many workers a sprint spins up, that’s how many times the 33k floor repeats — the number the source calls a “floor” turns into something close to a literal per-worker cost for us, with none of the cushioning cache normally provides.
Our leader-worker model is exactly the most expensive scenario
The harshest finding in Systima’s post is also the most relevant one for me: the same task cost 121,000 tokens with a single agent, but jumped to 513,000 tokens once split across two sub-agents — because each sub-agent pays its own bootstrap cost, and then the leader reads its transcript on top of that. AgentSpace is already built around exactly this shape: the leader splits the task, workers proceed in parallel, and the leader tracks progress through the task board. The structure the source calls “the biggest multiplier” is our default mode of operating.
That doesn’t mean I think fan-out is the wrong call — parallel workers genuinely speed up a sprint. But I now see clearly that how many workers we spin up isn’t just a speed decision anymore, it’s a direct cost decision. The question of whether to leave a task to one agent or split it three ways now needs to weigh the token bill alongside speed.
The one exception: multi-step tasks flip the table
The one result that favored Claude Code also matters for us: on a multi-step task (write, run, test, fix), Claude Code batched its tool calls into a single request and came out ahead of OpenCode overall — OpenCode opened a separate request at every step and paid its smaller floor over and over. Translating that to AgentSpace raises a real question: is it cheaper to hand one worker a single broad task — “do these four steps in sequence” — or to split the same work across four separate, narrow tasks/workers? Per Systima’s data, the answer depends on the shape of the work: a serial, multi-turn job pays less floor inside one large agent; work that genuinely parallelizes wins by fanning out. I need to fold this distinction into sprint planning starting now — until today I was splitting tasks without ever making this call.
The size of our memory files goes straight to the bill
Another layer Systima measured: in a production setup, an instructions file (AGENTS.md/CLAUDE.md) added an average of 20,000 tokens to every request — and in one version, when that file was named incorrectly, the harness silently ignored it. We also feed workers their context and persistent agent memory through a file. That finding reminded me of two things: first, as a memory file grows, that growth gets rebilled on every single worker call; second, it’s risky to assume a file name or path is actually being read by the harness without verifying it. A silently-ignored file is both a memory loss and a money loss.
Cache instability matters less for us, but not zero
One of the more striking details in the source is that Claude Code rewrites its cache prefix mid-session on the same task, inflating cache writes up to 54x compared to OpenCode. That finding mostly applies to long, single-session interactive use — our short-lived headless workers don’t have a long session to rewrite in the first place, they’re one-shot. So this specific risk hits us less. But if the leader agent runs a long, open conversation for the duration of the sprint (tracking the task board the whole time), the same rewrite behavior could kick in there. I need to watch these separately: floor cost for workers, cache stability for the leader.
What I haven’t measured yet, what doesn’t change
To be honest: I’ve never systematically logged AgentSpace’s real per-sprint token cost — I’ve been watching the general trend on Anthropic’s usage dashboard, not doing a request-body-level measurement the way Systima did. I’m not claiming a new number of my own in this post; what I can claim is which mechanism applies to us too.
What doesn’t change is this: worker output quality has nothing to do with this measurement. Systima says so directly — both harnesses completed the same tasks correctly, the only difference was the price paid for the same result. On our side, too, the question isn’t “does Claude work better,” it’s “how much more are we paying for the same sprint output.”
What to do today
A copy-paste measurement checklist for your own headless Claude Code setup:
1. Run a one-line task with a fresh config dir + empty workspace (--print mode).
→ Read the input token count from the API/usage panel. This is your "floor" number.
2. Add your memory/instructions file (CLAUDE.md or AGENTS.md), rerun the same task.
→ Note the difference; confirm which file name is actually being read.
3. Add each MCP server you use one at a time and re-measure the same task.
4. Run the same task (a) with one agent, (b) split across 2 workers.
→ Compare the total token difference; this is your fan-out multiplier.
5. At the end of a sprint, compare worker-count × floor against the real bill.Those five steps are what I’m doing for AgentSpace next sprint. I’ll share the results.
The floor cost Systima measured isn’t a theoretical number for me — it’s a direct consequence of our leader-worker architecture, one that was just easier to ignore before I measured it. If you want to see how we’re building AgentSpace’s worker architecture and token discipline, take a look at AgentSpace.