The unit of account

A token is priced in fractions of a cent, and that price is the one everyone quotes. It is also the wrong unit. What a system actually costs is the cost of an answer you can accept, and a single unverified answer that turns out wrong does not save you that cost. It defers it. The retry, the review, and the debugging that follow a wrong answer shipped are the same expense, billed later and under a different name.

Software has priced this for a long time. Boehm and Basili’s 2001 defect-reduction list put avoidable rework at roughly 40 to 50 percent of the effort on a project, and noted that most of it traces to a small fraction of the defects. The lesson is not that rework is unavoidable. It is that the cost of a wrong answer lands downstream of the moment you produced it, so a ledger that stops at generation is not measuring the work.

AI-assisted development has made this visible at scale. Faros AI’s 2025 telemetry across more than ten thousand developers found that heavy AI users merged 98 percent more pull requests and completed 21 percent more tasks, while review time rose 91 percent and the metrics that measure whether software actually ships stayed flat. The output moved; the throughput did not. The 2024 DORA report put a number on the same effect: for every 25 percent increase in AI adoption, it estimated a 1.5 percent decrease in delivery throughput and a 7.2 percent decrease in delivery stability. More was generated and less was delivered. The volume did not disappear. It moved into review, where a person now reads it.

The answer is to verify before you ship, and verification is not free. It is a line item, and it has to earn its place. The cascade literature makes this explicit. FrugalGPT sends a query to a cheap model first and escalates only when a scoring gate rejects the cheap answer, and RouteLLM reports over 85 percent cost reduction on one benchmark at 95 percent of the strong model’s quality by routing only about 14 percent of queries to it. The gate is the mechanism, and the gate costs something of its own. It also has to be good. The JETTS benchmark found that model-based judges are competitive when reranking finished answers but worse than step-level verifiers at guiding a search, and that their written critiques did little to make the generator better. A judge you cannot trust is worse than no judge, because it accepts confident wrong answers with a straight face.

Here is the case against us, and it is real. Verification does not always pay. A controlled study of code execution in program repair let strong agents run the code they wrote, which is the strongest gate there is, and found it moved the resolve rate by about a point, 63 percent against 64 percent, and in some configurations the agents did better with execution turned off. The gate cost more tokens and more time and bought almost nothing. Below a certain stakes this is the normal result: the verification layer costs more than the failures it prevents, and the honest move is to leave it out. We will not pretend otherwise. Verification pays when the outcome is expensive to get wrong and cheap to check against something real. That is a narrow condition. It is the one we build inside.

So we account differently. The unit is not the token. It is the accepted outcome, and an outcome is accepted when it passes a check against executable ground truth, not when a model is confident about it. That definition is the whole discipline: it puts the cost of being wrong back on the same line as the cost of the attempt.

How that nets out on our own traffic is a measured claim, and we do not publish measured claims about ourselves. ◷ It goes public when a client can attribute its own number. Until then this is an argument, not a result, and we would rather you read it as one.