Your Claude model doesn't need Claude Code: the hidden harness tax in coding agents
HarnessTax: How Much Does the Harness Matter for Coding Agents?
A UC Berkeley and Arena study benchmarks 21 model–harness pairs across seven models and three harnesses (Claude Code, Codex CLI, Pi) on SWE-bench Lite and Terminal-Bench 2.0. Harness choice barely affects success rate but can swing cost up to 5x. Pi, a minimal open-source harness with four tools, matches richer harnesses, and models often perform best outside their provider's own harness.
Paying extra for essentially the same quality because the use of different harnesses is like paying a… Harness Tax.
- nojs
We really need better harness benchmarks. It seems there's no reliable source that benchmarks the main harnesses against all open source models.
I also wish the discussion around Pi did not always use cost/token count as the metric. It's amazingly token efficient, but how does it stack up again opencode and others if you don't care about token count?
My experience is that the harness is mainly polish preventing failed tool calls, bad edits, stuff like that, but doesn't make much difference to the overall "intelligence". But that opencode seems slightly more robust against stupid errors than out of the box Pi due to the additional context it forces through every thread.
- lukax
What matters more is that you use the tools that the target model was fine-tuned on.
E.g. for editing files with Claude models you should use Edit(file_path, old_string, new_string, replace_all) but with GPT models you should use apply_patch_call(patch) (where patch is a custom patch string with custom grammar).
It appears newer models are better at narive harness tool calls and worse at custom tools that look similar to default tools.
https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/
- Yashjain413
I think it’s really important, especially when you look at everything the tool does, from the execution loop and context management to feedback. The harness is basically the underlying source of truth.
With coding agents, what I’ve noticed is that a simple task can often be handled with a fairly simple harness. But the hidden cost is really around context. One of the more interesting things I’ve seen is that two different harnesses can make a similar number of model calls while consuming a very different amount of context.
I think I recently came across a paper comparing Claude Code and Pi that touched on this. More context, more tooling, focused context, simpler loops, all of these can lead to very different costs and performance, even when the number of model calls looks similar.
- Supermancho
The term "harness" here is being overloaded for the term "agent", which is worrying. Putting that aside, there are many factors that matter. The "harness" context, the execution pattern (parallel vs sequential), the ability to delegate to other models, etc.
Optimal harnesses use concurrent execution + subagents and are not stuck on one model. Cost and performance are impacted GREATLY by these tactics, regardless of the native agent context (instruction). This kind of single-harness analysis is shallow and misleading, although the finding that "Provider-specific optimization does not guarantee the best pairing" is probably correct, depending on how you measure.
It is a starting point.
- corv
My own findings are in line with this research:
Having a coding harness is critical but the differences between them are overstated.
Personally, I’ve replaced OpenCode with a thin wrapper around Pydantic-AI as the pythonic analogue to Pi-Agent for headless use via Hermes
They’d all do the job - I just prefer to compartmentalize for access control.
Keeping the harness’ surface area tiny had the added benefit of preserving my understanding and being able to adapt it to my preferred workflow effortlessly