Claude Code Burns 33k Tokens Before Your Prompt: A Token Overhead Deep-Dive

The Raw Numbers: What Actually Happens

Researchers at Systima ran a clean experiment: they intercepted the API calls from two coding agents—Anthropic's Claude Code and the open-source OpenCode—before any user prompt was injected. The goal was to measure the pre-prompt tax: the tokens consumed by system instructions, tool definitions, environment context, and conversation scaffolding before your actual question ever hits the model.

The results are stark:

• Claude Code: 33,000+ tokens of overhead
• OpenCode: ~7,000 tokens of overhead

That's a 4.7x difference. Your prompt hasn't even arrived yet, and Claude Code has already burned through more context than an entire chapter of a technical book. The full breakdown is available in Systima's original analysis.

This isn't a bug. It's a deliberate architectural choice with real downstream consequences for latency, cost, and the quality of the model's output on complex tasks.

Why Token Overhead Matters (More Than You Think)

Engineers tend to think of token overhead as a billing nuisance. It's much worse than that. High fixed overhead attacks three things simultaneously:

1. Latency under load. Every token of overhead must be processed by the attention mechanism before the model can generate a single output token. Claude Code's 33k preamble means your first token of actual response is delayed by the compute required to chew through those 33k tokens. On a busy afternoon, that's the difference between a snappy IDE and one that feels like it's thinking too hard.

2. Context window cannibalism. Claude's 200k context window sounds massive until you realize 33k of it is gone before you type a character. Add your prompt, a few files of code, some conversation history, and tool outputs—you're suddenly fighting for headroom. The model starts forgetting the system prompt, then the earlier tools, then the thing you asked it to do three turns ago.

3. Cost amplification. Every API call pays the overhead tax. If you're running 50 agent loops a day, that's 1.65 million tokens of pure overhead. At Claude's API pricing, this adds up to real money—money spent on tokens the model reads but you never asked for.

For Forward Deployed Engineers (FDEs) building customer prototypes, this overhead directly impacts whether a demo feels magical or sluggish. As we explored in How FDEs Turn a Messy Customer Problem into a Shipped Prototype in a Week, speed of iteration is everything. A 33k token tax on every turn slows that loop considerably.

Inside the 33k: Where Those Tokens Go

Claude Code isn't padding its system prompt with lorem ipsum. The overhead breaks down into several categories, each serving a purpose:

The tool definitions are the biggest chunk. Each tool requires a complete JSON Schema block describing its function, parameters, return types, and edge cases. Claude Code ships with a rich toolset—rich enough that describing it consumes a novella's worth of tokens.

Here's what a single tool definition fragment looks like conceptually:

{
  "name": "Bash",
  "description": "Executes a given bash command in a persistent shell session...",
  "parameters": {
    "command": {
      "type": "string",
      "description": "The bash command to run. Must be valid and free of harmful instructions..."
    },
    "description": {
      "type": "string",
      "description": "A clear, concise description of what this command does..."
    }
  }
}

Multiply that by 15+ tools, each with multiple parameters and extensive safety descriptions, and you hit five-digit token counts quickly.

OpenCode's 7k: A Different Architectural Philosophy

OpenCode takes a fundamentally different approach. Instead of shipping a maximalist system prompt with exhaustive tool definitions, it operates on a principle of just-in-time context injection.

The core insight: the model doesn't need to know about the WebFetch tool if the current turn only requires reading a local file. OpenCode dynamically injects only the tools, context, and instructions relevant to the immediate task.

This isn't just a prompt engineering trick—it requires architectural support:

• A tool registry that can selectively expose definitions
• A context manager that evaluates relevance before injection
• A prompt assembler that builds the final payload per-turn rather than once at startup

The result is a lean 7k token preamble that grows only when needed. For simple file edits, it stays small. For complex multi-tool operations, it expands—but only as much as the task demands.

This approach echoes patterns we've seen in other agent architectures. When building a Multi-Agent Research Assistant That Plans, Searches, and Writes a Brief, you quickly learn that not every agent needs every tool. Specialization reduces overhead and improves focus.

Practical Impact: Latency, Cost, and Context Cannibalism

Let's put numbers to the impact. Assume you're running a coding session with 20 agent turns (a typical debugging or feature-building session):

Claude Code overhead per session:

• 33,000 tokens × 20 turns = 660,000 tokens of overhead
• At $3/M input tokens (Claude 3.5 Sonnet): ~$1.98 in pure overhead
• Time-to-first-token penalty: ~2-3 seconds per turn (cumulative ~50 seconds of waiting)

OpenCode overhead per session:

• 7,000 tokens × 20 turns = 140,000 tokens of overhead
• At $3/M input tokens: ~$0.42 in pure overhead
• Time-to-first-token penalty: ~0.5 seconds per turn (cumulative ~10 seconds)

The cost difference per session is modest. But the latency difference is noticeable, and the context window pressure is significant. In a 200k window, Claude Code's overhead consumes 16.5% of available space before you start. After 20 turns with tool outputs, you're likely pushing 150k+ tokens, and the model's attention starts degrading.

For FDEs deploying prototypes at enterprise customers, this math changes. When you're running Production Agent Migration to GPT-5.6 scenarios, every percentage point of overhead reduction compounds across thousands of API calls.

How to Audit Your Own Agent's Overhead

You don't need to take Systima's word for it. You can measure your own agent's overhead with a straightforward approach:

Step 1: Intercept the API call. Most LLM frameworks let you log the full request payload. With the Anthropic Python SDK, enable logging at DEBUG level. With LangChain, use callbacks. With direct API calls, log the request body before sending.

Step 2: Count tokens before the user message. Extract the messages array and count tokens for everything up to—but not including—the first user message. Use a tokenizer (tiktoken for OpenAI models, the Anthropic tokenizer for Claude) for accurate counts.

Step 3: Categorize the overhead. Break it into system prompt, tool definitions, and context. This tells you where to optimize.

Step 4: Profile per-turn growth. Some agents accumulate overhead across turns (conversation history, tool outputs left in context). Measure overhead at turn 1, turn 5, and turn 20 to see if you have a leak.

Here's a minimal Python snippet to get started with the Anthropic SDK:

import anthropic
import json

client = anthropic.Anthropic()

# Enable request logging by wrapping the call
original_create = client.messages.create

def logging_create(*args, **kwargs):
    print(f"System prompt tokens (est): {len(kwargs.get('system', '')) // 4}")
    print(f"Tool count: {len(kwargs.get('tools', []))}")
    return original_create(*args, **kwargs)

client.messages.create = logging_create

For a deeper dive into agent architecture patterns, our guide on building a SQL Analyst Agent That Answers Questions Over Your Free Postgres Database walks through structuring tools and prompts for minimal overhead.

A Balanced Take: Overhead Isn't Always Waste

It's tempting to read "33k tokens of overhead" and conclude Claude Code is bloated. That's not the full picture.

The case for high overhead:

Claude Code's exhaustive tool descriptions and behavioral guidelines produce more reliable tool calling. When the model has complete, detailed schemas for every tool, it makes fewer mistakes about parameter types, doesn't hallucinate tool names, and handles edge cases more gracefully. The overhead buys robustness.

Anthropic's approach also means Claude Code works reliably out of the box across diverse environments—different shells, operating systems, and project structures. The environment context that looks like overhead is what prevents "command not found" errors when the agent assumes you're on Ubuntu while you're on macOS.

The case for low overhead:

OpenCode's dynamic approach trades some of that robustness for speed and cost efficiency. It works brilliantly when the task is well-scoped and the environment is predictable. But it may stumble on edge cases where a tool it didn't inject would have been the right call.

The real lesson isn't that one approach is better. It's that overhead is a design dimension you should actively manage, not a fixed cost you accept. The right level depends on:

• Task complexity: Simple tasks need fewer tools
• Reliability requirements: Production systems may justify more overhead
• Context window pressure: Long-running sessions benefit from leaner prompts
• Cost sensitivity: High-volume applications amplify overhead costs

For FDEs building customer prototypes, the sweet spot often leans toward lower overhead during development (where iteration speed matters) and higher overhead in production (where reliability matters). This mirrors the pattern in Deploying an LLM Feature at an Enterprise Customer, where the prototype and production versions of the same feature often have different optimization targets.

FAQ

Q: Does the 33k overhead apply to Claude Code only, or to the Claude API in general?

The 33k figure is specific to Claude Code, which is Anthropic's agentic coding tool. The base Claude API has minimal overhead—just your system prompt and any tool definitions you provide. The bloat comes from Claude Code's own scaffolding.

Q: Can I reduce Claude Code's overhead myself?

Not directly. Claude Code's system prompt and tool definitions are managed by the application, not exposed for user editing. You can influence overhead indirectly by keeping your CLAUDE.md file concise and your project structure clean, but the 33k baseline is largely fixed.

Q: Is OpenCode a drop-in replacement for Claude Code?

OpenCode is open-source and model-agnostic, but it's a different tool with a different workflow. It's not a 1:1 replacement. If you're evaluating alternatives, consider your specific needs around tool reliability, model flexibility, and IDE integration.

Q: How do I measure token overhead for other agents like Cursor or Copilot?

Most commercial coding agents don't expose their raw API calls. For tools that use local models or allow API key configuration, you can set up a proxy (like mitmproxy) to intercept requests. For black-box tools, you're limited to inferring overhead from latency and behavior patterns.

Q: Will future models make this overhead problem irrelevant?

Larger context windows help, but they don't eliminate the latency and cost problems. A 1M token window still takes time to process, and you're still paying for those tokens. The overhead problem becomes less urgent with bigger windows, but it never becomes irrelevant. Efficient prompt design is a durable skill.