What a correct answer costs

You can look up what a token costs. You cannot look up what a correct answer costs. That gap is the line item almost nobody budgets, and it widens as models get cheaper.

When a team prices frontier-model work, it prices generation: tokens in, tokens out, times volume. That math assumes every task is one-shottable, and that the first answer is the answer. Almost nothing worth paying for behaves that way. You do not buy answers from a frontier model. You buy attempts, plus the passes it takes to learn which attempt was right. Call it the one-shot illusion: the price assumes one pass, the work takes N, and the cost of accuracy is whatever happens in passes two through N.

I have spent the last three months inside evals that run tens of thousands of dollars a month in tokens, and the failure mode is always the same. The first output looks finished. A frontier model writes a design doc that reads beautifully and code that looks nearly perfect, and it holds right up until you read one layer deeper. The cost of getting AI right at scale is not in that first pass. It is in every pass that confirms the first one was actually right, and tech leaders have not started budgeting that line.

Token cost dropped, review time did not

Sonar’s State of Code survey of more than 1,100 developers, released January 2026, found 96% do not fully trust AI-generated code to be functionally correct. Only 48% always check it before committing. The same survey found 38% say reviewing AI-generated code takes more effort than reviewing a human colleague’s. Sonar sells code-quality tooling, so it has a stake in the gap it measures. The direction still holds: generation got cheap, and the checking did not. The cost scales with the number of passes, not with the price of any one pass.

The cleanest measurement of that hidden cost comes from METR’s randomized trial. The study put 16 experienced open-source developers through 246 real tasks on mature repositories they had contributed to for years. With AI tools allowed, they took 19% longer. Afterward, they estimated the tools had sped them up by about 20%. The cost was real, and the perception of it ran in the opposite direction, which is what a hidden cost looks like on a graph. Rishi Baldawa calls the effect the verification tax: a developer “spent more time fixing AI-generated code than they saved generating it, but that cost is diffuse enough that it doesn’t register as ‘AI made me slower.’”

You do not buy answers from a frontier model, you buy attempts.

It is not only code, it is facts

While writing this post, I ran a research pass to pull recent sentiment on AI cost. The first tool returned nothing. A second pass through web sources surfaced a confident secondary claim: METR had walked back its 19% slowdown finding in a February 2026 update. That claim would have rewritten a paragraph. The primary source, METR’s own February 2026 post, shows the reverse. METR kept the 19% result intact and is rebuilding a later experiment that selection bias had already spoiled, because the developers who benefit most from AI kept refusing the no-AI arm.

One generated claim, one verification pass, one averted error. The pass that caught the error cost more than the pass that produced it.

The same property makes a single passing run meaningless on its own. A frontier model can return five different answers to the same question, so one correct-looking answer tells you nothing until you check it against something. Verification is not overhead you can optimize away. It is the price of using a stochastic system to produce something that has to be right.

The questions that actually set the budget are about counts, not rates.

Where the money actually goes

The per-pass cost compounds hardest inside agent loops. Each step resends the accumulated context, so by step 20 you have paid for the system prompt and the running history twenty times. Tom’s Hardware reported on May 23, 2026 that agentic workflows can burn up to a thousand times the tokens of a single query in the worst case. The same report says the climbing bills pushed some large engineering orgs to rein in usage. Not every pass is a human reading output. Many passes are automated: a test suite, a validator, a cheaper model that checks the expensive one’s work. A small model as the verifier drops the per-pass cost by an order of magnitude, and prompt caching trims the repetition the same way. Both lower the cost of each pass. Neither lowers the number of passes, and the number of passes is the term that dominates.

At the portfolio level, that unbudgeted pass count is what MIT’s NANDA research, reported by Fortune, measured. The research found 95% of enterprise generative-AI pilots delivered no measurable impact on profit and loss. A pilot that demos in one pass and needs five in production did not fail because the model was weak. It failed because nobody priced passes two through five: the review time, the re-prompting, the human who reads every output before it ships.

The questions that actually set the budget are about counts, not rates. How many passes does a model need to validate its own success and get the facts completely right? How many models does a change run through before you trust it? How many rounds of human and AI review before you would bet the business on a major change? Those counts come into focus once you are past the honeymoon phase, when a beautiful first output stops counting as done.

The honest unit cost of frontier-model work is generation plus every verification pass, divided by the outputs that cleared the bar you would hold a human’s work to. Most budgets quietly run that ratio at one pass, where the work looks cheap. Run it at the number a task actually needs, which is rarely one, and the figure changes enough to plan against. You do not control the generation price. You control the pass count, and verification costs something even when the first answer happens to be right. Log the passes each task takes for a week before you price the next one. That number, not the per-token rate, is the bill.

Verification is not overhead you can optimize away.