Most estimates for an AI job at volume are one multiplication: a token price times a token count. The bill has two more terms. Every unit has to be checked, by a model or a person, and every unit that fails the check has to be made again and checked again. Whether those two terms are a rounding error or most of the cost depends on one thing you control, the checking design, and one thing you have to measure, the failure rate.
This post defines the three-term model and works it through for a single unit of writing at three failure rates and three checking designs, using Anthropic's published per-million-token rates as read on September 22, 2026. It is arithmetic over a price list. We did not survey anyone, test any model, or measure any failure rate; the rates are quoted with their date and the failure rates are chosen to show the shape of the curve.
- 01With a cheaper model doing the checking, generation dominates until failures pass 62.5%.In the worked example, a Sonnet 5 check on Opus 5 output costs under a quarter of the generation. Checking plus rework only overtakes generation at a failure rate no one would ship at.
- 02With the same model checking its own class of output, the crossover is 26.8%.A same-model verification pass costs more than half of generation on its own. Add rework and checking is the larger term at any failure rate above about a quarter.
- 03With a person checking, checking is the bill at any failure rate.Three minutes of review at $60 an hour is $3.00 against $0.065 of generation. Verification and rework are 98% of the total whether 5% or 30% of units fail.
- 04The crossover moves with the checking design, not the model price.Halving the generation price changes the totals but barely moves the crossover for a human design, because the human term does not scale with tokens. Decide how you check before you price the job.
01 — The modelThe formula, every term defined
For one unit of work, the expected cost is generation plus verification plus rework. Generation is the input tokens times the input rate plus the output tokens times the output rate, for the model that makes the unit. Verification is whatever it costs to decide whether the unit is acceptable: a second model reading the brief and the output and writing a verdict, a person spending a stated number of minutes at a stated rate, or both. Rework is the failure rate times the cost of generating and verifying again. The model assumes one retry; a unit that fails twice costs more, so the numbers below are a floor.
- GenerationInput tokens × input rate + output tokens × output rate, for the generating model
- G
- VerificationA second model pass priced the same way, or minutes × an hourly rate, or both
- V
- ReworkFailure rate f × (G + V), assuming one retry that is generated and checked again
- f × (G + V)
- Expected cost per unitThe three terms summed; checking share is (V + rework) ÷ total
- (G + V) × (1 + f)
The last line is the useful one. Because rework multiplies both earlier terms, the total is simply generation plus verification, scaled by one plus the failure rate. Checking plus rework overtakes generation exactly when the failure rate exceeds generation minus verification, divided by generation plus verification. That expression is the whole sensitivity analysis, and it says the crossover is fixed by the ratio of the two costs, not by the level of either.
02 — The numbersThe worked example
One unit is a piece of writing generated from a 3,000-token brief into 2,000 output tokens. Generation uses Claude Opus 5 at $5 per million input tokens and $25 per million output tokens, which is $0.065 per unit. Design A checks with Claude Sonnet 5 at $2 and $10, reading the brief and the output (5,000 tokens) and writing a 500-token verdict: $0.015. Design B does the same check with Opus 5: $0.0375. Design C is a person spending three minutes at $60 an hour: $3.00, an assumption stated here and not a measurement of anyone's review speed. All model rates are from Anthropic's pricing page as read on September 22, 2026, without caching or batch discounts.
| Checking design | Failure rate | Cost per unit | Checking + rework share |
|---|---|---|---|
| A: cheaper model checks | 5% | $0.084 | 22.6% |
| A: cheaper model checks | 15% | $0.092 | 29.3% |
| A: cheaper model checks | 30% | $0.104 | 37.5% |
| B: same model checks | 5% | $0.108 | 39.6% |
| B: same model checks | 15% | $0.118 | 44.9% |
| B: same model checks | 30% | $0.133 | 51.2% |
| C: a person checks | 5% | $3.22 | 98.0% |
| C: a person checks | 15% | $3.52 | 98.2% |
| C: a person checks | 30% | $3.98 | 98.4% |
Checking plus rework as a share of cost per unit, at a 15% failure rate
Computed from Anthropic's published rates read September 22, 2026; illustrative failure rate03 — The lineThe sensitivity line
Apply the crossover expression to each design and you get one number per design: the failure rate above which checking and rework cost more than generation.
Cheaper model checks
Below this, generation is the larger term. No production job runs here, so with a cheap checker the generation price is what to optimise.
Same model checks
Whether a job sits above or below this is an empirical question about that job, not something this post answers. Above it, the checking pass is the cost to optimise, by making it cheaper or by lowering the failure rate it has to catch.
A person checks
Verification costs 46 times generation before a single failure. The generation price is irrelevant to the bill; the review minutes are the bill.
The premise this post set out to test was that checking, not generating, is the real cost of AI work. The honest result is narrower: it is true whenever a person is in the loop and false whenever a cheap model is, and the boundary in between is set by the ratio of the two costs. What the model price does is move the totals, not the boundary. A separate measurement of ours makes the same point about where the money is not, in our cost-per-task benchmark, where cache reads rather than fresh input held most of the tokens in seventeen of the eighteen runs; those measured figures are not reused here.
04 — The inputWhat makes the failure rate knowable
Every number above hangs on a failure rate, and a failure rate is not a feeling. It is the fraction of a sample that fails a written acceptance rule. To know yours, write the rule first, draw a random sample of finished units, have the checker you intend to use apply the rule, and have a person apply it to a subset of the same units so you also know how often the checker is wrong. Then you have three numbers: the failure rate, the checker's miss rate, and the checker's false-alarm rate. The first sets rework; the second sets what escapes to your customer; the third sets wasted rework.
The sample size does not need to be large to be useful. What it needs is to be random, drawn after the process is fixed, and repeated when anything upstream changes: the brief template, the model, the checker's prompt. A failure rate measured on last quarter's model is a historical fact, not an input. How we budget the same kind of job at fixed monthly spend is in our post on what a fixed AI budget buys; the harness overhead that sits on top of both terms is in our harness-cost post.
Design A and design C are not the only choices. A cheap model check followed by human review of only the units the model flags, plus a small random sample of the ones it passed, keeps the human minutes proportional to the failure rate instead of the volume. In the worked example that turns a $3.00 term into about fifteen cents plus the sample at a 5% failure rate. The formula handles it: V becomes the model check plus the failure rate times the human minutes.
05 — The scopeWhat this is and is not
This is arithmetic over published prices on a stated date. It is not a benchmark of any model, not a measurement of any team's failure rate, and not a claim about which model fails more often. The unit sizes, the review minutes and the hourly rate are assumptions chosen to be typical, and every one is printed so you can replace it. The prices will change; the formula and the crossover expression will not. If you want the same model run on your own job with your own measured failure rate, our AI transformation service starts every volume engagement with exactly that sample.
06 — Next stepThe checking design sets the crossover; the failure rate decides which side you are on
Price the check before the generation, then measure the failure rate on a real sample
Write the acceptance rule. Cost one unit of generation and one unit of each checking design you would actually use, at today's published rates. Compute the crossover for each. Then draw a random sample of real output and measure where you sit. If you are above the crossover, the money is in the checker; if below, it is in the generator.