Every coding agent says it is efficient.
Almost none of them publish the bill.
So we ran the boring experiment: the same bugfix, the same model, the same API, the same prices, and a byte identical prompt, once through opencode and once through the coding agent inside Locally Uncensored.
Headline: opencode averaged 2157 credits over three runs.
Our 2.6.6 agent finished the identical task for
1298.
That is about 40 percent less, and even the cheapest opencode run came in 29 percent above our number.
The interesting part is not the headline.
It is why the gap exists, and it is not the reason most people guess.
Setup A cost comparison is only worth reading if everything that drives cost is nailed down.
What was held constant: Held constant Value Task Fix a failing test in a small npm repo, then commit Repository Three files, a one line bug in , tests red at the start Prompt Byte identical, sha256 Model Endpoint The same OpenAI compatible API for both agents Prices Same account, same tier, same per token rate Counting One wire proxy in front of the API, credits read before and after every run opencode 1.18.21 from npm, wired as an OpenAI compatible provider, , otherwise defaults Success was defined before the runs, not after: passes exactly one commit, with the required message only changed clean working tree at the end All four runs cleared that bar.
Nothing failed, so cost is the only variable that moved.
The numbers Run Credits Requests Prompt tokens Success opencode, run 1 1679 8 98,789 yes opencode, run 2 2433 11 146,058 yes opencode, run 3 2358 11 146,387 yes Locally Uncensored 2.6.6 1298 16 74,629 yes Locally Uncensored 2.6.5 4395 30 257,270 yes Read the last row first.
Our own shipped agent from one release earlier is the most expensive thing in that table, by a lot.
This is not a chart built so that we win by construction.
It is a chart that shows what one efficiency pass is worth, and the previous version of our own software is the loser in it.
Why the gap exists The tempting explanation is that one agent is smarter and needs fewer steps.
That is not what happened, and the direction is the reverse of what you would expect. opencode used fewer turns than we did.
Eight to eleven requests against our sixteen.
If you scored this on steps, opencode wins.
The bill went the other way because of what every single request carries.
Per request opencode Locally Uncensored 2.6.6 Prompt tokens per request 12,349 to 13,308 4,664 Tool catalogue size 21,188 bytes 7,703 bytes Credits per prompt token 0.01700 / 0.01666 / 0.01611 0.01739 That last row is the honest one.
The billing rate is the same.
Credits per prompt token land within a few percent across all four runs, and ours is marginally the highest of the set.
Nobody got a secret discount.
The entire difference in the invoice is token volume, not token price.
Two things drive that volume, and both are familiar to anyone who has built an agent loop: The fixed block.
A tool catalogue of 21,188 bytes against 7,703 bytes is roughly three times the standing overhead, and you pay it again on every call in the loop, whether the model touches those tools or not.
Context decay.
As the agent works, the transcript grows.
Old tool output that stopped mattering ten steps ago keeps getting resent at full length unless something actively trims it.
Put together, a fixed block that size pushes every opencode request past 12,000 tokens.
Six agent steps at that weight already approach our total consumption for the entire task.
What changed between 2.6.5 and 2.6.6 The 4395 in the table is not a strawman we built for the article, it is what we shipped in the previous release.
Between 2.6.5 and 2.6.6 we went after exactly the two items above: how big the fixed block is, and how much of the transcript gets resent.
Measured over the same set of tool driven runs, that cut credit consumption by 78.6 percent, and on the longest run in the set by 80.4 percent.
The opencode comparison is simply what fell out whe