- 47comments
- 215comments
- 5comments
- 107comments
- 2comments
- 100comments
- 109comments
- 12comments
- 14comments
- 216comments
- 29comments
- 70comments
- 51comments
- 36comments
- 293comments
- 48comments
- 29comments
- 37comments
- 243comments
- 23comments
- 71comments
- 4comments
- 22comments
- 2comments
- 214comments
- 16comments
- 49comments
- 4comments
- 22comments
- 15comments
Does this extend to open models like GLM 5.3? This would mean that simply changing the harness to Pi reduces cost in half?
I've found the experience of using Pi with local models feels a lot snappier than both OpenCode or Claude Code.
The provider's middleware also plays a role. I just completed some benchmarks on my bespoke harness and Kilo Code. There's a chart on my LI post here: https://www.linkedin.com/posts/joshheitzman_i-ran-a-fuller-r...
In the case of DeepSeek-V4-Flash-0731 on deepinfra.com there was little difference when both used high reasoning. In the case of that same model on together.ai there was a substantial difference between the two (high reasoning for both again). When using together.ai with Kilo Code the LLM was having a lot of trouble making successful edits. In some cases that meant a lot tries at using the tools and in others it worked around by running scripts. Meanwhile it used the tools from my harness just fine. I've specifically tried to make my tools easy for all of the open weight LLMs to use correctly. That was inspired by getting some errors from Kilo Code at the beginning of the year telling me that the model was having trouble and I should use a smarter model.
Much of the extra weight of Claude Code and Codex harness are (ostensibly?) for security and alignment purposes. Whether they are effective is an open question, but leaving those dimensions out and calling it a tax is disingenuous, just turning insecurity into a negative externality.
"Why pay the waste disposal tax? Dumping into the ocean is free!"
Pi actively omits any sort of guardrails and sandboxing in the name of speed and simplicity, so it is not shocking that it is faster and simpler.
Doubling the cost of something in the name of vague security is standard operating procedure for big enterprises, maybe even quite cheap.
It's not hard to sandbox Pi without adding anything substantial to the actual size of the system prompt, which is what HarnessTax is mostly measuring. Wrapping it in nono.sh costs approximately zero tokens.
(I do think Pi should ship with more than zero builtin sandboxing though)
You can sandbox with tool hooks, at least in antigravity, I think a lot of other harnesses support similar features. Sandboxing via the prompt is just dangerous and unreliable.
I have a couple hundred line TUI that just clones an LXD container and I get all my repos and infra isolated in 5s with pi having isolation to that container. Swap between any instance. Port forward to host all automatic.
Funny to me how stuff is described these days. Seems like some people lack the full understanding of all these different systems and really overcomplicate their harness setups or use super bloated all in one tooling.
Do you have any links that would explain this?
I'm looking at changing my AI harness and am definitely interested in this
I tried putting my agent in an LXC / Incus container but then I also needed it to process videos stored on a NAS, and that was not easy at all. I tried a FUSE-based NFS client [1] but it was very flaky and would randomly report files having zero length and fail processing.
[1] https://github.com/facebookarchive/nfusr
Wonder if you have any source to back that data, unless you are referring to the security code to detect the user and their usage itself to prevent against unauthorized usage patterns?
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.
While sub-agents could theoretically stack turtles indefinitely, there’s limited room when going up the stack because someone will have to take responsibility beyond “git blame”, and that lands squarely with a person or legal entity.
claude code feels mildly shitty to use in the way that every other vibe-coded-project-got-out-of-hand project does, which is like, not that bad, but it's fucking ridiculous for a 2 trillion dollar company's main companion product
It's pretty great to not use, conversely.
I’m still baffled as to where these 100x valuations came from. Amazon’s market cap is $2.65T, and I don’t see how any AI company comes within a faint whiff of that sort of value.
As the model gets smarter, you need to tell it less
As the black box gets bigger, you need to stop expressing yourself even more.
Perhaps, but then the value of each thing you tell it goes to.
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
One thing I am missing to be able to move out of Claude Code, is the auto mode (and the soft_deny and hard_deny settings that can be tuned), with it's classifier checking the output.
It's the killer feature from me personally, often when wanting to troubleshoot for example things like Kubernetes workloads. LLMs are now really good at it, but we doesn't want them to like delete a pod.
Other harnesses like Codex have often on static rules, like the allow/deny of claude code, that can filter out based on regex. It's quite good already, but sometimes the model can find a way to write something that wasn't anticipated, or in a convoluted way.
After, I guess it's something that can be added in an open-source harness like Pi, and add like this new Jev model or something else equivalent
Claude Code/Codex charge the user for their extremely bloated one-size-fits-all system prompts (including safety instructions and other stuff users dont want).
In my experience if you're using OpenAI/Claude models and paying API costs, almost every other harness beats Claude Code/Codex in cost.
Say I'm using Claude Code or GPT Codex's harnesses but also sending some queries to the respective Anthropic and OpenAI models via OpenRouter.
Do harnesses and therefore sending the queries directly to the LLM providers have caching and other benefits that OpenRouter does not provide? Would I get any of those benefits if I simply proxied any requests to the major providers' harnesses through OpenRouter? Or only if the requests go straight from the harness to the provider's API?
Your question is worded kind of confusingly, but all caching is handled on the inference layer, and by all major providers. In short, caching should work as long as you are sending requests to the same model and provider.
Apologies. I guess my main question is just is there a benefit to routing directly to a provider through its own harness vs just sending chat requests to those providers using OpenRouter or similar as a proxy?
As per your response it sounds like at least caching would happen for any provider regardless of the request's origin.
If this is mostly because of the size of the system prompt, then perhaps in long horizon tasks the "tax" will be less obvious.
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.
A good benchmark would require a decent number of smaller scoped one off tasks to larger multi step refactors, and also one shot full project of simple to complex varieties. In addition to a series of “conversational” ambiguity filled one-liners.
I really disliked how opencode works IMO; the harness tries to do to much in my mind. Switching to Pi was a breath of fresh air for me, and I even use hax for some of my local needs where i dont want to have the giant pile of fertilizer that is NPM or PIP installed.
The harness becomes more and more important, the smaller the model is as you need to offload context management as well as memory to the harness. The big models basically just need a bash prompt tooling and you let the model manage everything inside its own context.
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.
I have been using jcode for past two weeks, honestly I feel its much better compared to Opencode.
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/
I’m not really a dev, so hefty pinch of salt with this take, but doesn’t this feel like we’re just inventing new “fuzzy” regex with much more required compute?
comparing LLMs to regex is like the OG dropbox comment (https://news.ycombinator.com/item?id=9224).
I can understand this take 4-5 years ago but I have no idea how that's your position in 2026
Doesn’t that have more to do with the templating of tool-calls and how using them are presented to the models?
Or is that just why my model likes to break out of the sandbox, going strait to exec shell command and editing files using python on the cli?
This is true. For example, the other day I was doing some testing with DeepSeek-V4-Flash-0731, and I gave it a tool called "EditFile" with "old_content" argument. It ignored the tool definition and called it with "old_string" instead, presumably because it was trained on a bunch of Claude Code traces.
So either make sure your tools look nothing like the tools in the popular harnesses, or make them similar.
It matters about as much as where you leave the electrician, he’s gonna use what tools he has to get the job done with what he has.
This is interesting. We built our own harness (CodeBot, an agent for Delphi) and it currently uses OpenAI models; we tuned it for specific behaviours and patterns and I find its behaviour better than Codex. Same models underneath.