Selecting an agent harness: memory and task cost
Measure memory footprint, turn count, and context growth after the worker agent is running.
A base harness can pass a first-request token comparison and still be expensive to operate.
Production worker agents are running processes. Long-lived worker sessions consume resident memory. Customer-specific sessions compete for host capacity. Multi-step tasks accumulate history, tool outputs, file snippets, logs, retries, and corrections.
Part 4 measures the costs that show up after the agent is running. Two of them matter more than most first-pass harness comparisons admit:
- Memory per active session, because it controls how many workers fit on a host.
- Total tokens per completed task, because the lowest first-turn token cost can still lose if the harness needs more turns to finish.
Selecting the right harness
A five-part series comparing 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
Startup token cost sets the floor. The task decides the bill.
If you run many concurrent workers, memory footprint sets host density. In our default single-turn measurement, peak resident memory ranged from about 90 MB to about 516 MB.
If you run long or multi-step tasks, total per-task cost matters more than the default tool set. Turn efficiency and context management decide the final token spend.
Memory footprint
Each active worker session is a running process. Its memory footprint determines how many sessions fit on a host before you need more capacity.
That matters for any product where workers are durable, customer-specific, or frequently concurrent. Token efficiency affects model spend. Memory footprint affects infrastructure density.
We measured peak resident memory for a single-turn session with each harness in its default configuration.
| Harness | Runtime | Peak resident memory |
|---|---|---|
| Goose | Rust | about 90 MB |
| Codex CLI | Rust | about 134 MB |
| DeepAgents | Python | about 272 MB |
| Claude Code | Node | about 330 MB |
| OpenCode | Node | about 516 MB |
Memory footprint changes host density
Peak resident memory for a single-turn session in the default configuration.
- Lightest default
- Goose, about 90 MB
- Heaviest default
- OpenCode, about 516 MB
- Operational impact
- Memory footprint sets host density for high-concurrency agents
The largest measured process used about six times the memory of the smallest. Runtime was a major driver: the Rust harnesses were the lightest in this measurement, while the Node and Python harnesses used more memory.
This axis is independent of startup token cost. OpenCode is relatively efficient on fixed tokens but heavy on memory. Goose is light on both in this measurement. That does not make Goose the answer for every agent, but it does show why token-only comparisons miss a real production cost.
Host density
One local session is easy to host. The hard case is many at once.
| If your workload has... | Memory footprint means... |
|---|---|
| Many customer-specific workers | More resident sessions, more pressure on host density. |
| Long-lived workspaces | Idle or paused sessions still need a lifecycle strategy. |
| Burst concurrency | Peak memory decides how much headroom you need. |
| Small margins per task | Infrastructure density can matter as much as model spend. |
If concurrency is part of the product, measure memory under your own workload before standardizing on a harness.
Per-task token cost
Part 1 measured startup token cost per turn. A task costs more than one first request.
The total token cost depends on:
| Driver | Why it matters |
|---|---|
| Turn count | A harness that finishes in fewer turns can win even with a higher startup token cost. |
| Context growth | Tool outputs, file snippets, logs, and conversation history accumulate. |
| Compaction behavior | Summarization and context pruning decide how much history stays in the request. |
| Tool result handling | Large tool outputs can dominate the context if the harness does not offload or summarize them well. |
This is where context management earns its keep. Two harnesses using the same model can reach similar answers with very different total token spend if one needs fewer turns or carries less history forward.
Measurement plan
Measure memory and per-task tokens with tasks that look like the work your worker will actually do.
| Measurement | What to record |
|---|---|
| Peak resident memory | The high-water mark for one active session and for concurrent sessions. |
| Turns to completion | How many model turns the harness needs for each task. |
| Total input tokens | Startup token cost plus accumulated context across the task. |
| Total output tokens | Model output across all turns. |
| Tool-output growth | Whether tool results are summarized, truncated, offloaded, or carried forward. |
Do not run this only on toy prompts. Use at least one task that reads files, one task that calls tools repeatedly, and one task that requires correction or retry. Those are where context management starts to matter.
Implications for selection
Startup token cost tells you the floor. Memory footprint and per-task cost tell you whether the harness scales.
Use this rule:
- High concurrency: measure memory first.
- Long or multi-step tasks: measure total per-task tokens first.
- Short, frequent tasks: startup token cost matters more.
- Mixed workloads: keep separate profiles instead of forcing one harness shape onto every agent.
The lowest-cost harness is the one whose cost profile matches the agent you are shipping, not the one with the smallest number in a single table.