How to select a harness to build your agent, part 1: baseline token efficiency
Same model, different harness, very different fixed cost per turn. How to measure baseline token efficiency and use it to choose.
An agent harness is the scaffolding around the model: the system prompt, the tool set, and the machinery for skills, hooks, and subagents. The model reasons. The harness decides what the model sees on every turn. Two harnesses running the same model on the same task can cost very different amounts, because they put different amounts of scaffolding in front of the model.
This series is a practical guide to choosing a harness to serve as an agent's runtime. Each part isolates a single dimension you can measure and compare across harnesses. Part 1 is baseline token efficiency: the fixed number of tokens a harness spends before your agent does any work.
We compare five harnesses throughout: Claude Code, OpenCode, Codex CLI, DeepAgents, and Goose.
Why baseline token efficiency matters
Every turn an agent takes begins by sending the model a system prompt and a set of tool definitions. That payload is fixed overhead. It is present whether or not the turn uses it, on every turn of every session. Call it the startup tax.
Prompt caching softens the repeat cost: after the first turn a cached prefix bills at roughly a tenth of the full rate. The first turn still pays in full, and any cache miss (a gap longer than the cache window, or a change that invalidates the prefix) pays in full again. So the startup tax sets the floor under both your token bill and your first-token latency. On a high-volume agent it is one of the larger costs you control by choosing well.
How to measure it
You can measure this for any harness in a few minutes, without its cooperation. Point the harness at a local HTTP endpoint that records the first request it sends to the model API, give it a trivial prompt, and read the payload. Count two things: the tokens in the system prompt, and the tokens in the tool schemas. Their sum is the startup tax.
We ran this with the model held constant (Claude Sonnet 4.5, and gpt-5-codex for Codex), each harness in a clean configuration with no user files or extra servers, counting every harness with one tokenizer so the results compare directly.
The baseline numbers
| Harness | System prompt | Tool schemas | Tools | Startup tax |
|---|---|---|---|---|
| Goose | 404 | 694 | 5 | 1,098 |
| OpenCode | 2,005 | 4,863 | 10 | 6,868 |
| Codex | 4,371 | 4,249 | 10 | 8,620 |
| DeepAgents | 6,668 | 4,496 | 11 | 11,164 |
| Claude Code | 5,859 | 19,343 | 24 | 25,202 |
The startup tax ranges from 1,098 to 25,202 tokens for the same model and the same trivial prompt: a 23x spread, paid on every turn.
Reading the numbers: the tool set drives the cost
Most of the tax is in the tool schemas. Claude Code sends 5,859 tokens of system prompt and 19,343 tokens of tool definitions across 24 built-in tools, several of which (schedulers, task queues, workflow and worktree controls) a typical agent never calls. Per tool, its schemas run about twice as verbose as the other harnesses'.
When you evaluate a harness, read its default tool list, not only its prompt. The size of that list is the main driver of baseline cost, and much of it is capability a given agent will not use.
Raw defaults are not comparable, so normalize
A low default tax can mean an efficient harness or an empty one. Goose sends 1,098 tokens because it loads almost nothing until you add extensions. To compare fairly, hold the capability constant.
First normalization: strip each harness to the minimum and add one real tool. We built the same small agent on each, a support agent whose only custom tool searches a knowledge base over MCP, and measured again.
| Harness | Default tax | Minimal + one tool | What the harness allows |
|---|---|---|---|
| Goose | 1,098 | 359 | starts minimal, add only what you need |
| OpenCode | 6,868 | 1,899 | disable built-in tools per agent |
| Claude Code | 25,202 | 5,734 | one flag drops all built-in tools |
| Codex | 8,620 | 9,119 | tool set fixed, adding a tool grows it |
| DeepAgents | 11,164 | about 11,164 | coding CLI, tool set fixed |
Two results here transfer to any harness you evaluate:
- Adding a capability costs about the same everywhere. The custom tool added about 110 tokens on every harness. A skill adds roughly a line. A hook adds nothing to the request, because it runs in the harness. The differences between harnesses come from the harness's own overhead, not from the agent you build on it.
- Harnesses differ in what you can take away. Some start minimal and let you add. Some ship a full tool set and let you disable it per agent. Some fix the tool set and let you only add, so mounting your tool makes the agent larger and you cannot get below the built-in coding tools.
Claude Code drops from 25,202 to 5,734 with one flag that disables its built-in tools. What remains is a roughly 5,600-token system prompt oriented toward coding, which you keep while you use the harness defaults.
Second normalization: give every harness the same capabilities. A real agent usually needs to connect tools over MCP, load skills, run hooks, spawn subagents, run code, run a shell, and reach the web. With all five configured to that bar plus the knowledge-base tool:
| Harness | Startup tax at equal capability |
|---|---|
| Goose | 5,916 |
| OpenCode | about 6,978 |
| Codex | about 9,119 |
| DeepAgents | about 11,164 |
| Claude Code | 12,711 |
At equal capability the spread narrows to about 2x. The 23x gap in the first table was mostly an empty harness measured against a full one. The gap that remains at equal capability comes from two things: how verbose each harness's tool schemas are, and how much of its default set you are required to keep.
How to use this when you choose
Baseline token efficiency is one input to the decision, and it gives a clear rule:
- For a coding agent, the coding-oriented harnesses earn their default tool set. The baseline cost buys capability the agent will use.
- For a non-coding agent such as support, operations, research, or an internal tool, the default tool set is overhead on every turn. Choose a harness you can reduce to the tools the agent needs. Favor harnesses that start minimal or let you disable built-ins per agent. Be cautious with harnesses whose tool set is fixed, because the agent will carry coding tools it never calls.
Once you have chosen, two levers set the number: the size of the tool set you load, and the verbosity of the harness's schemas. You control the first directly, by loading only the tools the agent uses.
What this measures, and what it does not
These numbers are a snapshot of specific CLI versions and will move as the tools change. We counted every harness with one tokenizer for comparability; a provider's own tokenizer shifts the totals by a few percent without changing the order. Baseline token efficiency is the fixed per-turn floor. It does not account for what an agent spends completing a task, which depends on how many turns the harness takes and how it manages context.
This is Part 1. The series continues with capability parity across harnesses, dynamic tool loading (loading tools only when the agent needs them), memory footprint, and total token cost per task.
Measure it for your stack
The method reproduces in an afternoon: a proxy that records the first request a harness makes, and a script that counts the system-prompt and tool-schema tokens. If you want the rig we used, or help applying it to your own harnesses, get in touch.
Karta runs agents on all five of these harnesses, which is why we measure them the same way. If you want the same agent to run on more than one, that is what we build.