Selecting an agent harness: startup token cost
Measure the fixed prompt and tool-schema tokens a base agent harness sends before useful work begins.
Teams building agents have a basic architecture choice: assemble the agent from an agent framework, or start from an agent harness and do harness engineering on top of it.
Frameworks such as LangGraph and AutoGen give teams primitives for building explicit flows. Harnesses such as Goose, DeepAgents, Claude Code, OpenCode, and Codex CLI give the model a runtime environment: instructions, tools, skills, hooks, subagents, shell or code execution, and project context.
For highly capable worker agents, the harness shape is often the more practical starting point. The model can adapt the workflow dynamically, bring in skills as the task changes, connect to external systems through MCP, and still anchor important steps in deterministic checks or actions through hooks.
That leaves a harder question: which base harness should a team build on?
This series is about worker agents, not coding assistants as an end product. The agent might be a tax analyst for a customer, a code-review specialist for an engineering team, a marketing expert, a support operator, or another domain worker that uses tools and judgment over many steps. The base harness matters because each candidate arrives with different defaults and biases.
Part 1 measures one of those defaults: the fixed prompt and tool-schema tokens sent before the worker starts the task.
Selecting the right harness
This series compares candidates for teams building worker agents on top of a harness.
Startup tokens
Fixed prompt and tool-schema tokens before work starts
Capability requirements
Tools, skills, hooks, subagents, shell, web, and code execution
Tool loading behavior
Config-time composition versus runtime loading for large catalogs
Memory and task cost
Memory footprint, task turns, and total per-task token use
Workload recommendation
A workload-specific recommendation and measurement plan
In this post
We measure startup token cost as system prompt tokens + tool schema tokens loaded before the worker starts the task.
In clean defaults, Goose started at 1,098 tokens and Claude Code started at 25,202 tokens. After normalizing every harness to the same production-capability bar, the range was much narrower.
The measurement separates two questions: what does the base harness carry by default? and what can this worker remove?
Harness context
Selecting a base harness means selecting the default context your worker agent carries.
That context has a cost even when the worker does nothing interesting. Before the model answers, before it searches, before it calls a tool, the harness has already sent instructions and tool definitions. The model has to read them. Your bill and latency reflect them.
| If your worker is... | The selection risk | What you want to learn |
|---|---|---|
| A tax analyst | Compliance checks, document tools, and review hooks matter more than repo-editing tools. | Whether the harness can expose the right deterministic checks without carrying unrelated tools. |
| A code-review specialist | Repo context, shell access, policy hooks, and review skills may all be useful. | Whether a coding-oriented default helps review quality enough to justify its cost. |
| A marketing expert | Research, brand memory, approval hooks, and publishing tools matter more than a shell. | Whether the harness can stay narrow while still loading specialized skills and integrations. |
| A platform team supporting many workers | One bad default multiplies across every worker and session. | Whether teams can choose minimal profiles per workload. |
Measurement
Startup token cost = system prompt + tool schemas loaded into the first model request.
It is the fixed floor under each turn. Prompt caching can reduce repeat billing, but the first turn and every cache miss still pay the full price. That makes startup token cost a useful early screen, especially when several harnesses can meet the same capability bar.
Startup tokens are sent before task work
The first model request already contains the harness context.
The work request
Reasoning begins
Measurement setup
The measurement is intentionally simple, and it works for any harness candidate.
- Point the harness at a local endpoint that records the first model request.
- Start the harness in a clean project with no extra user files or tool servers.
- Send a trivial prompt.
- Count the tokens in the system prompt and the tool definitions.
We compared Claude Code, OpenCode, Codex CLI, DeepAgents, and Goose. The task was held constant, and every request was counted with the same tokenizer so the numbers are comparable. Codex CLI used its native model path in the rig; this lens evaluates request shape, not model quality.
These numbers are a snapshot of specific versions. Treat the method as the durable part of the selection process.
Default payloads
The first pass measured each harness as it ships, before we adjusted any candidate for a specific worker job.
| Harness | System prompt | Tool schemas | Tools loaded | Startup tokens |
|---|---|---|---|---|
| Goose | 404 | 694 | 5 | 1,098 |
| OpenCode | 2,005 | 4,863 | 10 | 6,868 |
| Codex CLI | 4,371 | 4,249 | 10 | 8,620 |
| DeepAgents | 6,668 | 4,496 | 11 | 11,164 |
| Claude Code | 5,859 | 19,343 | 24 | 25,202 |
Where the startup tokens come from
Raw default payloads split into system prompt tokens and tool-schema tokens.
- Largest default
- Claude Code, 25,202 tokens
- Main driver
- Tool schemas dominate the largest payload
- Smallest default
- Goose, 1,098 tokens
The default payloads differed substantially. Claude Code sent 25,202 fixed tokens, while Goose sent 1,098, before any harness was tuned for a workload.
The source of the tokens matters more than the ratio by itself.
| What drives the token count | What we saw | Why it matters |
|---|---|---|
| Tool count | Claude Code loaded 24 built-in tools by default. | Every tool definition is schema text the model reads before the task. |
| Schema verbosity | Claude Code's tool-schema block was 19,343 tokens. | A small tool list can still be expensive if schemas are verbose. |
| Default philosophy | Goose started small; coding harnesses started with richer toolkits. | A cheap default may mean "minimal", not "equally capable". |
Interpretation
Raw defaults are not the final selection score. They reveal the harness's default posture. Goose starts near empty. Claude Code starts with a large coding environment. Both choices can be correct for the right workload.
Capability-normalized comparison
A production selection comparison has to hold capability constant.
For the second pass, we built the same small worker-agent shape on every harness: one knowledge-base search tool over MCP, no coding tools unless the harness required them, and no extra project files. That test answers a practical selection question: if this worker only needs a knowledge tool, how much harness context must it still carry?
| Harness | Default startup tokens | Minimal profile + one tool | What this tells you |
|---|---|---|---|
| Goose | 1,098 | 359 | Starts minimal and lets you add only what the worker needs. |
| OpenCode | 6,868 | 1,899 | Built-ins can be disabled per worker. |
| Claude Code | 25,202 | 5,734 | A flag removes built-ins, but a coding-oriented system prompt remains. |
| Codex CLI | 8,620 | 9,119 | The tool set is fixed in this profile; adding the knowledge tool grows it. |
| DeepAgents | 11,164 | about 11,164 | The coding toolkit remains part of the request. |
Two conclusions matter more for selection than any single number.
- Adding the custom capability was cheap. The knowledge-base tool added about 110 tokens across harnesses. The large differences came from the harness itself.
- Removing unused defaults is the lever. For worker agents that are not primarily repo-editing assistants, the valuable feature is not the smallest default. It is the ability to strip the request down to the tools the worker actually uses.
Equal-capability payloads
Most real worker agents eventually need more than one search tool. They need some mix of tool connections, skills, hooks, subagents, code execution, shell access, web access, isolation, and budget controls depending on the workload.
When all five harnesses were configured to the same broader capability bar, the token counts moved closer together.
| Harness | Startup tokens at equal capability | Practical reading |
|---|---|---|
| Goose | 5,916 | Still lean, but no longer nearly empty. |
| OpenCode | about 6,978 | Close to Goose once normalized. |
| Codex CLI | about 9,119 | Mid-pack with a fixed coding-oriented profile. |
| DeepAgents | about 11,164 | Stable because the default set already carried the core capability. |
| Claude Code | 12,711 | Much lower after reducing built-ins, still carrying a rich coding harness. |
Normalization changes the comparison
Defaults show posture. Equal capability shows the practical comparison.
- Default range
- 1,098 to 25,202 tokens
- Equal-capability range
- 5,916 to 12,711 tokens
- Selection method
- Compare defaults, then compare the smallest capable profile
After normalization, the smallest measured profile was 5,916 tokens and the largest was 12,711. That is why defaults are only the first measurement. The comparison that matters is the smallest configuration that can still do the job.
Selection implication
If the worker reviews code, investigates repos, edits files, and runs shells, a coding-oriented harness can justify a larger baseline.
If the worker analyzes documents, answers support questions, performs operations workflows, routes tickets, searches internal knowledge, or works inside a product UI, choose a harness profile you can keep small.
Applying the measurement
Run this measurement before you standardize on a harness.
| Step | Command-level outcome | What to record for selection |
|---|---|---|
| Capture the first request | The exact JSON payload sent to the model API. | System prompt, tool array, model, harness version. |
| Count startup tokens | One token total for prompt plus tools. | System tokens, tool-schema tokens, total. |
| Create a minimal profile | The smallest agent that can still do the real job. | Which built-ins were disabled, which tools remain. |
| Add one real capability | A representative MCP tool, skill, hook, or subagent. | Incremental tokens added by the capability. |
| Repeat for equal capability | Same capability bar across candidate harnesses. | The normalized startup token cost and remaining fixed tools. |
Use the result as an early filter in a broader harness-selection scorecard. The next questions are how many turns the worker needs, whether it solves the task, how reliable its tool calls are, how much memory and compute it uses, and how easy it is to operate.
Scope
This post measures the fixed request floor. The broader harness decision also needs task completion cost, quality, reliability, permissions, isolation, developer experience, and operational controls. A harness can spend more upfront and still win if it finishes in fewer turns or avoids operational mistakes.
This is also a market snapshot. Harness defaults change quickly. Re-run the measurement on the versions you plan to ship.
Conclusion
The right harness is workload-specific, so the selection process has to be workload-specific too.
For repo-heavy workers, pay for the tools the worker will use. For tax, marketing, support, research, and operations workers, avoid carrying a coding toolkit through every user turn unless the workload needs it.
Karta supports harness-native agent projects because teams will not all make the same choice. A durable worker agent needs the right harness for its job, plus the operational layer around it: identity, release management, isolation, budgets, observability, and rollback.
This series applies the same standard across five selection lenses: startup token cost, capability fit, tool loading, run cost, and workload-specific recommendation.