Why Some Coding Agents Burn 33k Tokens Before You Type Anything

You hit “run” on your coding agent expecting a quick reply.

Instead, your dashboard climbs. The model hasn’t generated code yet, you didn’t even type the prompt… and somehow you already “spent” a big chunk of tokens.

That’s the core discovery behind the Claude Code vs OpenCode comparison: the two harnesses (agent wrappers) can start their sessions at radically different token baselines. One effectively arrives at the model already loaded with ~33,000 tokens of system prompt/tool scaffolding. The other starts closer to ~7,000. And once you understand where those tokens come from—and how prompt caching really behaves—you can make far more predictable (and cheaper) agent deployments.

Tokens are budget, not decoration

A token is a unit of text the model processes. Roughly speaking, tokens are where cost, latency, and context-window usage all meet.

In an agentic setup, the “prompt” you care about (your task instructions) is only a slice. Before the model can reason, you also send:

• A system prompt: the hidden instructions that steer the agent’s behavior.
• Tool schemas: descriptions of callable tools (functions) the agent may use.
• Conversation scaffolding: extra messages the harness injects to manage tasks, agents, plans, reminders, and tool orchestration.

The expensive part is that these pieces can be resent—or only partially reused—on every turn.

Measuring token overhead at the API boundary

It’s tempting to guess where tokens go from screenshots or logs inside an agent UI. But token spend is metered by the provider at the API boundary, so the comparison in the source narrative used a logging proxy between each harness and the model endpoint:

harness → logging proxy (captures request payload + response usage) → model endpoint

Two things matter here:

1. Captured request payload: the exact JSON each harness emitted (system blocks, tool definitions, messages).
2. Usage returned by the API: fields that separate normal input tokens from cache reads and cache writes (plus output tokens).

Why this is so important: a request payload can look “the same” to a human, but the provider bills based on tokenized content and cache behavior. Measuring both sides prevents comforting-but-wrong stories.

The “floor”: fixed cost before your real prompt exists

Consider the simplest task in the comparison: “Reply with exactly: OK”. It’s intentionally tiny so the harness overhead dominates.

Claude Code’s hungry baseline

Claude Code’s first-turn payload includes:

• A much larger system instruction set
• Many more tool schemas (not just a few tools, but orchestration-heavy agent tooling)
• Injected <system-reminder>-style blocks before the actual user prompt arrives

In the measured setup, that meant the first request arrived at the model at roughly ~32,800 tokens (after calibration) rather than ~6,900.

The beginner-friendly takeaway: tool schemas aren’t “free metadata.” They’re text the model must process. If your harness loads an entire orchestration suite up front, you pay for it every session.

OpenCode’s near-minimal request

OpenCode’s first request is closer to “minimal viable harness”: a smaller system block and a shorter tool schema set. So the first-turn payload lands around ~6,900 tokens in the same kind of setup.

Prompt caching: why it helps… until it doesn’t

Prompt caching is a provider feature where repeated prompt prefixes can be reused without redoing the expensive computation.

With OpenAI’s caching model, the system caches the longest previously computed prefix of your prompt and starts matching at a minimum prefix size (and in fixed increments), so stable leading text is what you want. (openai.com)

With Anthropic/Claude-style caching, the idea is similar: the provider can reuse computation for parts of the prompt, but you still pay for cache behavior (reads and writes) according to published multipliers. (platform.claude.com)

The tricky part: “cache-friendly” means prefix-stable

Cache hits require the cached prefix bytes/tokens to match what gets sent later.

In the comparison narrative, OpenCode’s request prefix was effectively byte-identical across runs, so it could reuse the cached payload efficiently.

Claude Code, however, was described as rewriting large prompt-cache segments mid-session—meaning the “longest stable prefix” condition keeps breaking. When that happens, the harness can keep generating cache writes (often billed at a premium) and also consume context window in ways caching doesn’t erase.

A useful mental model: caching isn’t a magic “discount button.” It’s more like a library checkout—if you keep returning different books, you lose the benefit.

Configuration bloat: your repo can be the second system prompt

A pattern that shows up repeatedly in real deployments: teams store large instructions in repository files such as AGENTS.md or CLAUDE.md, and then the harness automatically includes them.

In the narrative comparison, a 72KB instruction file added on the order of ~20,000 tokens to every request, and adding multiple MCP servers (tool integrations) added further tokens.

MCP servers are components that expose capabilities (tools) to the agent over a standardized interface. The agent then loads schemas describing how to call those capabilities. Each schema is text the model must read.

So the “token floor” isn’t just the harness itself—it’s also your environment.

Subagents: multiplication by orchestration

Agent loops often spawn multiple helper workers. In the comparison, a small task cost about 121,000 tokens when done directly, but about 513,000 tokens when fanned out to two subagents.

Why such a jump? Because every subagent typically has its own bootstrap overhead, and the parent agent also consumes the transcript.

This is the hidden tax of architecture: even if each worker is “small,” orchestration layers can create expensive repeated baselines.

When the gap closes: fewer requests can beat a larger baseline

Here’s the twist that keeps this from being a simple “winner/loser” story.

On a multi-step task, Claude Code’s whole-task total came out lower than OpenCode’s in the comparison narrative, because it reduced the number of model requests by batching tool calls.

That matters because, with large-baseline harnesses, the session’s cost shape is roughly:

• baseline × number of requests
• plus conversation growth

So if harness A pays a high baseline but uses fewer requests, and harness B pays a lower baseline but uses many more turns, you can end up with similar totals.

A question that often comes up in production budgets is: Why does “smaller request” sometimes lose to “bigger request” over a whole task? The answer is request count and tool batching.

Practical engineering lessons (the parts you can control)

Once you’ve seen a token floor, you can treat it like an engineering budget line item.

1. Trim tool schemas and instruction payloads. Large orchestration toolkits and big repo instruction files can dominate the prompt before reasoning even starts.
2. Stabilize the prefix for caching. Prompt caching rewards consistent leading content. Prefix rewriting can turn cache reads into cache writes and undermine savings. (openai.com)
3. Watch orchestration patterns, not only model choices. Subagents and per-turn tool-calling strategies can multiply baseline overhead.
4. Measure what the provider bills. A logging proxy that captures request payloads and usage fields is the difference between folklore and engineering.
5. In regulated environments, behavior logging matters. The EU AI Act’s record-keeping expectations include documentation of system behavior, so “what did my agent actually send?” becomes an audit-friendly question, not a debugging inconvenience. (ai-act-service-desk.ec.europa.eu)

Final thought: treat tokens like memory writes

Caching can reduce recomputation, but it doesn’t remove the fundamental truth: agent harnesses send a lot of context on your behalf—sometimes repeatedly.

The Claude Code vs OpenCode comparison is valuable less because of a single number and more because it teaches a production mindset: before you optimize code generation quality, confirm your token plumbing. Once you do, “why did costs jump?” stops being a mystery and becomes something you can measure, predict, and redesign.