AI price sheets are quoted in units nobody budgets in: dollars per million tokens. This guide translates. By the end, you'll be able to take any provider's price page and your own volumes and produce the number you actually need — the cost per unit of finished work.
The billing unit: tokens
Models bill by the token — a chunk of text roughly three-quarters of an English word. A page of dense text is on the order of 500–700 tokens; a typical invoice's text might be 400; a 40-page board pack, 25,000 or more.
Every call has two meters running at different rates:
- Input tokens — everything you send: instructions, the document, the data. Typically the cheaper meter.
- Output tokens — everything the model writes back. Typically 3–6× the input rate.
This asymmetry has a practical consequence: what you ask for changes the bill. An extraction that returns eight fields costs pennies of output; asking the same model to "explain its reasoning" can multiply output tokens — and the invoice — several times over for no operational benefit.
The modifiers: caching and batch
Two price-sheet lines matter more than the headline rates:
Cached input. When calls repeat the same leading content — the same instructions, the same document schema, on every one of your 10,000 invoices — some providers automatically bill the repeated portion at a steep discount (often ~90% off), while for others caching is opt-in engineering work. For high-volume, template-driven finance workflows, the cached rate can matter more than the base rate, and whether it applies by default is a fair vendor question. (Our editions freeze and publish exactly these rates per model — cached rates included only where caching is on by default.)
Batch processing. Work that can wait — overnight statement runs, monthly categorization backfills — often qualifies for a batch tier at ~50% off in exchange for delayed results. Much of finance's AI-suitable volume is not real-time. If your workload can tolerate "results by morning," you should probably not be paying real-time prices for it.
The arithmetic: from rates to cost per unit of work
Worked example — invoice extraction. Suppose: instructions + invoice ≈ 1,200 input tokens (900 of them identical across invoices and cache-eligible), output ≈ 250 tokens. At illustrative rates of $2 per million input, $0.20 per million cached input, and $10 per million output:
| Component | Tokens | Rate /M | Cost |
|---|---|---|---|
| Fresh input | 300 | $2.00 | $0.0006 |
| Cached input | 900 | $0.20 | $0.00018 |
| Output | 250 | $10.00 | $0.0025 |
| Per attempt | ≈ $0.0033 |
So ~$3.30 per thousand invoices per attempt. Cheap — but "per attempt" is not the number to budget.
The step everyone skips: divide by the pass rate
An attempt is only worth paying for if the result is usable. The budgetable number is cost per successful outcome:
CPO = cost per attempt ÷ pass rate
At a 96% pass rate, the example above is $3.44 per thousand invoices, plus a thin review stream for the 4%. At a 70% pass rate it's $4.71 — plus a human catching and redoing 300 invoices per thousand, which will dwarf the model bill. A cheaper model with a lower pass rate is routinely the more expensive option, which is invisible on any per-token price sheet. This division is the entire reason our benchmark reports CPO rather than token prices, and why models that never pass a workload are reported as DNF rather than as an attractively low number.
Three more budget lines that per-token thinking misses:
- Retries and verbosity. Some workflows re-ask on validation failure; some models simply write more tokens than others for the same task. Both are real cost drivers that only show up in measurement.
- Agentic multipliers. Tool-using, multi-step workflows call the model many times per unit of work. A twenty-step agent at $0.01 per step is $0.20 per outcome if every run succeeds — failures multiply from there.
- Review labor. Whatever your control design (see the controls guide) requires a human to check is part of the cost per outcome. Count it.
Reading a price sheet like a CFO
Questions that cut through a vendor conversation quickly:
- Base input, output, and cached input rates — and is caching default-on for our usage pattern?
- Is there a batch tier, and can our latency tolerance use it?
- For an agentic product: how many model calls per unit of work, measured, at what distribution?
- What's the measured pass rate on work like ours — with logs we can inspect, not a demo?
- What are prices contractually pinned to? Provider list prices change quarter to quarter — mostly downward in recent years, which is worth negotiating to inherit automatically.
The pattern behind all five: convert everything to your unit of work, then divide by the probability it's done acceptably. That's the whole method. Our editions do this arithmetic in public — frozen prices, measured pass rates, cost per outcome with confidence intervals — precisely so you can sanity-check any number a vendor shows you, and the calculator on each edition page scales the measured rates to your volumes.