Claude Code's 33k Token Overhead: What's Eating Your Budget

Every session you start with Claude Code, roughly 33,000 tokens of system prompt, tool schemas, and injected scaffolding leave your machine before your actual task description arrives. Add a real CLAUDE.md file and a handful of MCP servers, and that number climbs to 75,000-85,000 tokens before you have typed a single word.

That’s the central finding from a token-overhead analysis by Systima that drew 456 upvotes and 257 comments from the builder community. The numbers aren’t vague estimates - they come from a logging proxy placed between the agent harness and the model endpoint, capturing every byte sent and received. This post walks through what the analysis found, shows you how to audit your own projects, and gives you three concrete levers to pull.

What you need

You’ll need a Claude Code project you’re actively using, Node.js or Python for the logging proxy snippet below, and access to your Anthropic usage dashboard to verify cost impact. Familiarity with CLAUDE.md helps, but isn’t required.

Step 1: Understand where the 33k tokens actually go

The Systima analysis ran both Claude Code and OpenCode against the same model, machine, and tasks. On a one-line reply task, Claude Code consumed roughly 33,000 tokens of overhead. OpenCode consumed about 7,000.

That overhead breaks down into three buckets: the system prompt Claude Code sends to orient the model, the tool schemas for its built-in capabilities (like file reading or shell execution), and injected scaffolding that describes the current session context. None of this is your task. All of it is billed.

One important nuance from the analysis: the multiple is model-dependent. Re-running the same test against a newer model narrowed the gap to roughly 3.3x, because Claude Code sends newer models a smaller system prompt. Still significant, but worth knowing when you’re choosing which model to target for cost-sensitive work.

Step 2: Measure your actual overhead with a logging proxy

Before trimming anything, get a baseline. The snippet below wraps the Anthropic SDK and logs token counts per turn:

import anthropic
import json
from datetime import datetime

class TokenAuditClient:
    def __init__(self):
        self.client = anthropic.Anthropic()
        self.session_log = []

    def create_with_audit(self, **kwargs):
        response = self.client.messages.create(**kwargs)

        entry = {
            "timestamp": datetime.utcnow().isoformat(),
            "input_tokens": response.usage.input_tokens,
            "output_tokens": response.usage.output_tokens,
            "cache_creation_input_tokens": getattr(response.usage, "cache_creation_input_tokens", 0),
            "cache_read_input_tokens": getattr(response.usage, "cache_read_input_tokens", 0),
        }
        self.session_log.append(entry)

        print(f"[TOKEN AUDIT] in={entry['input_tokens']} out={entry['output_tokens']} "
              f"cache_write={entry['cache_creation_input_tokens']} cache_read={entry['cache_read_input_tokens']}")

        return response

    def dump_session_summary(self):
        total_in = sum(e["input_tokens"] for e in self.session_log)
        total_cache_writes = sum(e["cache_creation_input_tokens"] for e in self.session_log)
        print(f"\n[SESSION TOTAL] input={total_in} cache_writes={total_cache_writes} turns={len(self.session_log)}")
        print(json.dumps(self.session_log, indent=2))

# Usage
audit = TokenAuditClient()
# Replace your normal client.messages.create(...) calls with audit.create_with_audit(...)

Run this across a few typical tasks and note two things: the input token count on turn one (that’s your startup overhead) and the cache_creation_input_tokens across turns (that’s your cache write cost).

The cache write number matters. The Systima analysis found Claude Code re-wrote tens of thousands of prompt-cache tokens mid-session, run after run, producing up to 54x more cache write tokens than the comparison harness on the same task. Cache writes are billed at a premium rate, which is why your usage dashboard can climb fast even on tasks that feel lightweight.

Step 3: Apply the three-lever trim

Now that you have a baseline, here’s where to cut.

Lever 1: Trim your CLAUDE.md. The analysis found a 72KB instruction file adds roughly 20,000 tokens to every single request. Not per session - per request. Audit yours ruthlessly. Keep only instructions that change behavior in ways you’d notice. Move reference material (architecture docs, design decisions, background context) out of CLAUDE.md and into separate files you pull in explicitly when needed.

# CLAUDE.md - lean version

## Project conventions
- TypeScript strict mode. No `any`.
- Tests live in `__tests__/` next to the source file.
- Commit messages: conventional commits format.

## Do not
- Modify files outside `src/` without asking first.
- Install new dependencies without listing the reason.

That’s roughly 60 tokens. Compare it to a 72KB file at ~18,000-20,000 tokens. Re-run your audit and compare the first-turn input count.

Lever 2: Scope MCP servers per task. Five modest MCP servers add 5,000-7,000 tokens to every request. You probably don’t need your database introspection server active during a frontend styling task. Load MCP servers selectively based on what the current work actually requires, rather than enabling everything at session start.

Lever 3: Watch subagent costs. The analysis included a striking data point: a task that cost 121,000 tokens done directly cost 513,000 tokens when delegated through subagents. This is likely because subagents each pay the startup overhead again. For small, well-defined tasks, direct execution is dramatically cheaper.

Where this breaks

The overhead story isn’t uniformly bad for Claude Code. The same analysis notes that on multi-step tasks, Claude Code can batch tool calls into fewer requests, which means the per-session total can come out comparable to alternatives that re-pay their baseline on every turn. The meter starts higher, but session length and task complexity decide who wins overall.

The lean-context pattern above also has limits. Some CLAUDE.md content is genuinely load-bearing - if you strip too aggressively, you’ll see the model making decisions you’ve already codified elsewhere. Trim iteratively, verify behavior, then trim further. And if your workflow genuinely requires five MCP servers throughout a session, that overhead is paying for real capability; the goal is eliminating unused overhead, not minimizing configuration for its own sake.

Next steps

The three levers - trim CLAUDE.md to essentials only, scope MCP servers per task, and audit cache writes per session - are each independently valuable. Drop the token audit hook into your project now and get a baseline before changing anything. The numbers from your own sessions will tell you which lever to pull first.

The full methodology, including the raw comparison harness setup and per-model results, is in the Systima analysis. It’s worth reading if you want to understand the cache-write mechanics in detail or replicate the comparison yourself.