The hidden token tax of AI coding agents

The most useful AI coding argument this week was not about which agent feels smarter. It was about what the agent sends to the model before it even reads the task.

On July 12, Systima published a measurement comparing Claude Code and OpenCode at the API boundary. The headline number was sticky: in a trivial task that asked the tool to reply with exactly "OK", Systima measured roughly 32,800 first-turn tokens for Claude Code and roughly 6,900 for OpenCode. By July 14, the Hacker News thread had reached about 687 points and 378 comments.

That reaction was not only tool fandom. The post landed because many teams have quietly reached the same uncomfortable place. AI coding agents are useful enough to become part of real development work, but their cost and behavior are still hard to see. The prompt a developer writes is only a small part of the bill. The harness adds system instructions, tool schemas, repository instructions, MCP server descriptions, reminders, subagent plans, cache writes and conversation history.

The practical question is not "Claude Code bad, OpenCode good." Systima's own results are more nuanced than that. The question is whether teams can see what their agent stack is sending, why it is sending it, and whether the quality justifies the token load.

What Systima measured

Systima says it put a logging proxy between the coding harness and the model endpoint, then compared Claude Code 2.1.207 and OpenCode 1.17.18 on the same machine, tasks and model family. The study looked at a floor task, a one-tool task and a multi-step write-run-test-fix task.

The floor task is the one that spread. It asked the agent to answer with exactly "OK." In that setup, Systima measured Claude Code at about 33k tokens before meaningful user work and OpenCode at about 7k.

The reason, according to the payloads, was not the user's prompt. It was the wrapper. Systima says tool schemas dominated the baseline: Claude Code exposed 27 tools and about 99,778 characters of tool schemas, while OpenCode exposed 10 tools and about 20,856 characters. Even with tools removed, Claude Code's system prompt was about 26,891 characters, around 6.5k tokens, compared with OpenCode's 8,811 characters, around 2k tokens.

This is the hidden tax of agent interfaces. The agent can feel like a single terminal command. Underneath, it may be shipping a small manual to the model on every turn.

The result is not as simple as "smaller is better"

A lean baseline is attractive. It costs less, uses less context window and usually adds less latency. But Systima also found a case where Claude Code's heavier harness did not obviously lose.

In the multi-step task, Claude Code batched several tool calls into fewer model requests. OpenCode made more one-tool-per-turn calls. Because the baseline is paid again across requests, fewer requests can partly offset a larger baseline. Systima measured about 121k cumulative metered input tokens for Claude Code and about 132k for OpenCode on that specific Sonnet run.

That caveat matters. A tool with a heavy start can still be efficient if it solves the task in fewer turns. A lean tool can become expensive if it serializes too much. Token cost should be measured per useful task, not only per first request.

The Hacker News comments also pushed on methodology. Some users questioned the Meridian gateway used in the setup, the pinned model version, the effect of the gateway's own envelope, and whether toggles such as extended thinking survived the path. Systima acknowledged some of those caveats and said later Fable reruns changed parts of the picture.

So the honest conclusion is narrower than the viral headline: this is strong evidence that harness overhead can be huge and tool-specific. It is not a universal law that one agent is always cheaper than another.

Why teams suddenly care about token overhead

For individual developers, token overhead shows up as faster subscription burn, slower sessions or context that fills earlier than expected. For companies, it becomes a budgeting problem.

Claude Code's own cost documentation makes that clear. It says Claude Code charges by API token consumption, and that per-developer costs vary widely by model selection, codebase size and patterns such as running multiple instances or automation. The docs also recommend pilot groups, usage tracking, spend limits, organization analytics, OpenTelemetry and gateway-based metrics.

Anthropic's documentation gives enterprise reference points: average cost around $13 per developer per active day and $150-250 per developer per month, with 90 percent of users below $30 per active day. Those numbers may be reasonable for many organizations. They still require measurement, because the average hides outliers.

Forbes recently framed token spend as a new management metric after the early "tokenmaxxing" phase. The broader point is familiar to anyone who has run cloud infrastructure: adoption starts with enthusiasm, then the bill arrives, then governance catches up.

AI coding agents are now in that second stage.

Where the hidden cost comes from

The visible user prompt is usually not the expensive part. The expensive parts are structural.

Tool schemas are one. Every exposed tool needs a name, description and parameter schema. If the harness exposes file operations, search, shell, browser, planning, task management and MCP tools, the model receives a large menu before it sees the user's actual task. That may improve autonomy. It also consumes context and money.

Project instructions are another. A large AGENTS.md or CLAUDE.md can be valuable when it captures real repository rules. It can also become a landfill of old preferences, repeated warnings and vague style advice. Systima measured a real 72KB instruction file adding just over 20k tokens per request.

MCP servers add their own tax. Each server brings tool descriptions and schemas. Systima measured roughly 1,000 to 1,400 tokens per small public MCP server, per request, and warned that production servers with rich APIs can be much larger.

Subagents multiply the problem. If an orchestrator launches several agents and each one receives the same bulky repository instructions, tools and conversation setup, the team may pay the baseline many times before any code improves.

Finally, conversation history grows. A long session with multiple turns, reminders and intermediate results can spend a growing share of context on scaffolding and old state. Cache discounts help billing, but they do not make context window consumption disappear.

What to measure before arguing about tools

A practical rollout should start by measuring at the boundary. If you cannot see payload size, cache writes, cache reads, output tokens and request count, you are mostly debating vibes.

Separate model cost from harness cost. A premium model is one decision. A heavy wrapper around the model is another. Teams should know whether the bill comes from reasoning, tool schemas, repeated instruction files, MCP metadata, subagent fan-out or simply too many model turns.

Measure per task, not only per session. A refactor that costs 300k tokens but replaces two hours of senior engineer work may be a good trade. A tiny rename that costs 80k tokens because the agent dragged in every tool and instruction file is probably not.

Track by project and repository. Some repos need heavy context. Others carry bloated instructions because nobody cleaned them. The difference should be visible.

Track by agent mode. Planning, implementation, test repair, code review, dependency updates and documentation work have different token profiles. Routing every task to the same expensive setup is the AI version of running every cron job on the largest cloud instance.

Prompt rules are not a substitute for engineering process

One Hacker News subthread hit a practical point: if you tell the agent in a prompt to always run tests, it may spend tokens repeatedly reasoning about test policy and executing broad checks. Sometimes that is useful. Often it belongs in hooks, CI or task-specific scripts.

The same applies to style rules, security checks and release steps. If a rule is deterministic, put it where software can enforce it cheaply. Pre-commit hooks, pre-push hooks, CI jobs and repository scripts are boring, but they reduce the need for the model to remember and reinterpret the same policy every turn.

Use instructions for judgment. Use automation for repetition.

That division keeps the agent focused on the parts where language and reasoning matter: understanding the change, choosing the approach, navigating the codebase, explaining trade-offs and fixing failures that are not obvious from a static rule.

How to govern agent cost without killing adoption

The wrong response is to ban powerful agents because one benchmark looks expensive. The other wrong response is to hand everyone unlimited access and hope the invoice matches the demo.

A healthier rollout looks more like FinOps for AI development.

Start with a pilot group. Measure real work, not toy prompts. Include small fixes, code review, test repair, migrations and multi-file changes. Compare token spend with outcomes: time saved, bugs caught, PR cycle time and developer satisfaction.

Set budgets and alerts. A developer should know when a session is burning through context or subscription limits. Managers should see per-project and per-team trends without turning token tracking into surveillance theater.

Route tasks. Use the best model for work that needs it. Use cheaper models or smaller harnesses for routine edits, explanation, formatting and search-heavy chores. If an agent supports subagents, make sure subagents can step down to cheaper models when the work is narrow.

Audit instruction files. Remove stale rules. Split giant instructions into smaller skills or task-specific guidance where the harness supports it. Keep repository instructions concise and testable.

Audit MCP servers. Do not attach every server to every session by default. A database schema tool, browser tool, ticket tracker and cloud admin tool all have value. They do not all need to be in every coding prompt.

Watch cache behavior. Cache writes, cache reads and context window use are different things. A discounted cache read can still fill context and affect how much room remains for code.

Why this matters beyond coding

Coding agents are simply the first place where many teams can see the problem clearly. The same pattern will appear in sales agents, legal research agents, support automation, data analysis agents and internal operations bots.

Every agent framework carries overhead: role instructions, tool schemas, memory, policies, examples, retrieved context and conversation history. Some of that overhead improves reliability. Some is cargo cult. Without observability, teams cannot tell the difference.

The market is moving from "give the model more context" to "prove the context is worth sending." That is a good shift. It does not make agents less useful. It makes them more like infrastructure.

The practical lesson

The Systima post became viral because it named a cost many people felt but could not see. Thirty-three thousand tokens before the prompt is a dramatic example, but the lesson is broader: AI agents have a bill of materials.

That bill includes the model, the harness, the tools, the instruction files, the servers, the subagents and the organization's habits. If a costly agent produces better outcomes, use it. If it burns tokens on scaffolding nobody understands, fix the scaffolding.

The next mature phase of AI practice is not less AI. It is measurable AI. Teams should be able to answer a few plain questions: what did the agent send, what did it cost, what did it accomplish, and which part of the stack made the difference?