Why Claude Code Sends 33k Tokens First

Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k is a July 2026 Systima post comparing Claude Code, Anthropic’s coding agent, with OpenCode, SST’s open-source terminal coding agent. It asks why Claude Code appeared to burn far more tokens before the user prompt was even read. The useful takeaway is not that one tool is bad; it is that agent harnesses have real startup cost, and you should measure that cost on your own repo before turning it into habit, policy, or claude code training. Token overhead is the model input and tool traffic a coding agent sends before, around, or after your actual request.

Read the measurement as a harness story

Systima’s test was simple in spirit: put logging between the coding tool and Anthropic’s endpoint, capture requests, and compare the returned usage blocks. The headline result was loud: Claude Code sent about 33k tokens before reading the prompt, while OpenCode sent about 7k.

That number spread because it matched a feeling many developers already had. The usage meter seems to climb faster when an agent searches, plans, lists files, reads memory, or calls tools before doing the thing you asked.

The caveat matters. Systima says its traffic passed through a local gateway that added a roughly 6,200-token envelope. That means the absolute counts are not a clean retail bill for every user. The gap is still interesting because the wrapper was treated as a constant across both tools.

A good claude code workshop should start here, not with a sermon about saving tokens. Ask what the harness is doing before it has enough evidence to know whether the task is small, medium, or dangerous.

Give Claude Code its strongest case

The generous read is that Claude Code is buying context up front. A coding agent that edits real repositories needs more than your prompt. It may need git state, file layout, project memory, command conventions, and safety checks before touching code.

That can be the right trade. A trivial prompt like fix the failing checkout test may actually require reading package scripts, a test helper, an API route, and a migration. If the agent under-reads, the cost shows up later as broken edits and longer review.

This is especially true in repos with useful conventions. A concise CLAUDE.md, a small set of project commands, and well-scoped skills can help the agent avoid guessing. The trap is stuffing everything into always-on memory and then blaming the model when every request becomes heavy.

Claude Code’s side of the argument is performance-first. If the product is trying to be the best coding agent, not the cheapest shell wrapper, it may spend tokens to reduce uncertainty.

Take the cost argument seriously

The cost side is not just complaining about invoices. It is pointing at a product design question: should a coding agent do expensive exploration before it knows whether the prompt deserves it?

Developers in the discussion described a familiar pattern across agents: even small prompts can trigger tool calls, repo search, and context collection. That behavior feels clever when the task is risky. It feels wasteful when the prompt is hello, commit, or explain this one file.

The real issue is not a large system prompt by itself. It is the combination of large startup context, aggressive tool use, and opaque accounting. If the first visible response is cheap-looking but the hidden prelude is expensive, users cannot build good instincts.

The trap is switching tools based on one benchmark without checking your own workload. OpenCode looking lighter in this test does not prove it will be better for your repo, your permissions, or your review style. It proves the harness choice is worth measuring.

Test the question on one boring repo

The cleanest answer is a local experiment. Pick one small repo where you know the code well, such as a TypeScript service with an app/api/users route, a test file, and a package script. Run the same prompts through both tools, or through two Claude Code configurations, and compare what happens before the first useful answer.

Keep the task boring on purpose. Use prompts like summarize the route, fix one failing test, add one validation branch, explain the last diff, and commit the change. Boring tasks make overhead visible because there is less real work to hide it.

For a claude code workshop, this is the best exercise because it turns a flame war into a stopwatch and a token log. It also fits naturally beside the related training topic: conventions should make agent work cheaper and safer, not just more formal.

If you have MCP servers connected, split the run in two. First allow local filesystem reads only. Then repeat with your normal GitHub, issue tracker, docs, or database access. That separates Claude Code workflow overhead from integration overhead.

If you are comparing release behavior, keep the versions in the receipt. We used this same habit when tracking small workflow changes in claude-code 2.1.205 Fixes Workflow Edges: write down the version, the repo state, the command, and the evidence you reviewed.

Copyable experiment: settle it locally

Use this as a starter exercise plan. It is small enough to run in under an hour, and it gives you numbers from your own repo instead of someone else’s argument.

Copy this repo-local slash command note if you use project commands:

.claude/commands/measure-overhead.md

• Start from a clean worktree.
• Record Claude Code version, model, repo commit, and enabled MCP servers.
• Disable networked MCP servers for the baseline run.
• Run exactly one benchmark prompt.
• Do not ask a follow-up until the receipt is written.
• Record input tokens, output tokens, tool calls, first file read, changed files, tests run, and whether the answer was useful.
• Repeat the same prompt with normal MCP permissions.

MCP permission note: the baseline run should allow local repository reads and block GitHub, Slack, Jira, document stores, and database tools. Then repeat with normal permissions. If the second run is much heavier, your integration surface is part of the cost, not just Claude Code itself.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude code workshop?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude code training. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Why Claude Code Sends 33k Tokens First.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k — source
• Claude Code — getting started
• Claude Code — skills
• Claude Code docs: en hooks

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.