Your coding-agent bill is a harness tax, not a model tax.
A Berkeley study shows the harness around a coding model can move cost far more than results. What to measure before blaming the model.
Same model. Similar results. The cage around it can make the bill several times higher.
Berkeley ran a study called "HarnessTax" (Melissa Pan and coauthors).
Arena helped with API access.
Seven models. Three harnesses. Two coding tests. Same model price in every cage.
Three things stuck with me:
The harness moved the cost more than the results.
Success barely moved. Spend did.
Same model. Similar outcomes. Cost up to about 5x in the worst case.
More often about 1.5x to 2x.
This is about the cage. Not a provider fight.
A tiny harness still held its own.
One open setup, Pi, with just "read", "write", "edit", and "bash", sat near the best cost and results on both tests.
Turns can look the same. The bill does not.
In one provider harness, the opening prompt and tool setup were over 10x larger.
More features can still help on other work. More is not automatically smarter. You have to measure it.
Models travel.
A lab can ship the model and the harness together. That still does not mean that pair wins.
In nine of twelve comparisons, a different harness had the highest success.
Keep this about harnesses as a class. Do not make it about which lab lost.
One caveat before I lean too hard on this. It is only two open tests, and the sample is small. The prices are from a dated API list, not subscription prices, and harnesses count turns differently. A quiet quality gap at this size is often not proven, not proven gone.
This is where measuring cost to finish a task really makes the difference. If you can measure that, you know what your harness is doing. You can take model scores from SWE-bench and elsewhere, but the moment someone says this model works really well and you wrap your own harness around it, you may as well ignore those findings. You just added another gate, rail, and loop that may never have been validated the way those tests were built. The only way to really validate a model is identical harnesses, identical setups, identical problem statements, trying to resolve them. Same cage, same problems. That is model testing. Run the same model across different harnesses and that is a different test on its own. You probably need to do harness testing as much as you need to do model testing.
Provider harnesses can feel excellent. The class that includes products like GPT-6 Astra, Claude Code, and peers.
You also give up control. You cannot see how they run the job.
Stack your own rails and rules on top of their cage, and you can break what they already tuned.
That is a second harness tax.
Own the harness on an open model, and you can tune it to your real work for less.
That path needs you to know the model's quirks, how you prompt it, and how it calls tools.
(Open-model points near the best trade-off in the study are a data check. Not a claim that I run that stack.)
Own the harness. Rent the model.
Where are you still running a provider default without measuring cost per finished task?