Last week, a single number spread across every founder's feed in the District: $0.23. That was the reported cost of having one frontier model generate a working 3D Eiffel Tower. The comparison model, run on the identical task, reportedly consumed $33.45. I read that pair of figures, sat back, and felt the specific discomfort I have learned to trust โ the same one I felt in 2017, auditing whitepapers that promised decentralization while quietly reserving upgrade rights to four multisig keys. The math was clean. The question behind the math was missing.
Let me be precise about what that number actually is. What was published is a single point of spend, produced by a single run, on a single creative coding task. No success rate. No quality score. No token consumption ledger. No statement about whether the outputs were equivalent. And no batch or cache configuration disclosed. In any rigorous benchmark, that is not a result โ it is an anecdote wearing a decimal point. Yet it traveled because it fits a story everyone already wants to believe: one lab has cracked inference economics, and the other is expensive.
I have spent enough time inside measurement instruments to know what a gap like that is made of. A task cost is not a scalar. It is a product: input tokens times input price, plus output tokens times output price, times a caching discount, times one plus the retry rate, plus tool call overhead. If two vendors publish per-token prices that differ by five to fifteen times โ an ordinary spread across tiers โ then a 145x task level gap cannot be explained by price alone. The remaining ten to thirty times has to come from behavioral differences: how verbose the output is, how large the internal reasoning budget is, how many lines of code get emitted, how many times the run failed and restarted. Verbosity is not capability. Failure loops are not incompetence. But they are exactly the variables a headline strips out.
The second thing that vanishes is tier discipline. One of these companies ships a product ladder โ flagship, mid, light โ and has done so deliberately. The other publishes a single high end model. Comparing the cheapest rung of one ladder to the only rung of another is not an efficiency test. It is a comparison of two different industrial designs and then a claim that one design lost. That is a category error, and I have seen the same error in crypto for a decade: comparing an L2 without its bridging and sequencer costs to a mainnet transaction, then declaring the base layer obsolete. The architecture you omit is always the architecture that decides the answer.
Here is where the comparison does carry real signal, though โ and this is the part I would actually put in front of a founder. Run the unit economics out loud. An agent product handling a million tasks a month at twenty-three cents spends $230,000 on inference. The same product at $33.45 per task spends $33.45 million. That is not a margin difference. That is the difference between a business and a novelty. The meaningful threshold is not who is cheaper per token; it is who crosses the line where automated work becomes economically viable at all. At the cheap end, generating ten variations and selecting one becomes rational policy. At the expensive end, you generate once and you pray. Those are different workflows, different products, and eventually different companies.
But I keep circling back to the omission, because it is the same structural omission I spent a year writing about in 2020 when yield farm incentives were dressed as innovation. If the twenty-three cent output is a rough placeholder and the thirty-three dollar output is something you could ship to a client, the comparison is commerce, not engineering. The metric that matters is cost per successful task, multiplied by success rate. Not cost per attempt. A model that fails three times and returns something excellent is cheaper than a model that returns something unusable on the first try, regardless of what the invoice says.
And the number leaves out the baseline nobody wants to publish. What would this task cost on an open-weight model, self-hosted, on hardware already paid for? In my experience, the honest answer often undercuts both figures. Any cost comparison that omits that line is a marketing document with a data header. I have watched this pattern inside governance too: the proposal always benchmarks against the most expensive alternative, never against doing it differently.
There is also a subtle inversion worth naming. If task cost collapses by two orders of magnitude, total consumption does not stay flat โ it expands, often by more than the price fell. Inference revenue to the cheap provider can rise while unit price falls. So the narrative that cheap inference destroys the expensive one is not automatically true; what is destroyed is the ability of a high-end vendor to charge a premium it cannot quantify. Cost compression does not eliminate the expensive tier. It forces the expensive tier to prove its premium in the customer's revenue, not in its own press releases.
For builders reading this โ and I address you as someone who has spent a decade insisting that users should read the mechanism, not the claim โ the operational rule is simple. Replicate the run on your own task. Measure success rate, measure total spend including retries, measure quality blind. Then compute a single number: cost per acceptable output. If a vendor's figure collapses under that test, you have learned something worth more than the discount.
For those of us in the decentralization space, the mirror is uncomfortable. We make the same move constantly, comparing one protocol's headline throughput to another's while omitting the coordination cost, the sequencer dependency, the governance assumption. The cheapest number is almost always the one that measured the least. What would you find if you priced your own system the way you price your competitors โ with every retry and every failure counted?