Per-Token vs Per-Outcome AI Pricing: A Buyer’s Guide
Per-token pricing charges for the model’s work; per-outcome pricing charges for yours — and the difference matters because only one of them maps to the value a buyer actually receives.
Two AI quotes can describe the same task and still be impossible to compare, because one is priced per token and the other per outcome. This guide explains what each model actually charges for, where per-token pricing comes from and when it is the right lens, why per-outcome pricing is rising for agents, and the one conversion that puts the two on the same axis. It references real, public pricing-model types factually and invents no vendor figures.
What per-token pricing charges for
Per-token pricing comes from the foundation-model layer: providers such as the major LLM vendors publish per-token (or per-million-token) rates for input and output, often with separate prices for prompt and completion. It is a real, transparent unit at the model layer — you pay for the compute the model consumes. The catch for a buyer of a finished task is that tokens measure the model’s effort, not your result: a verbose agent that burns more tokens to reach the same outcome costs more without delivering more.
What per-outcome pricing charges for
Per-outcome pricing charges per completed unit of work — a resolved ticket, a reviewed pull request, a booked meeting. It aligns price with the thing you are buying, and it shifts the efficiency risk to the vendor: if their agent is token-hungry, that is their cost to manage, not yours. Some vendors already publish per-outcome list prices (for example, a per-resolution charge on a support tool’s pricing page); where you cite one, record it as that vendor’s own published price, not as a market rate.
When each lens is right
Per-token thinking is the right lens when you are building on raw models and your cost is genuinely a function of tokens — you want to optimize prompt length, caching, and model choice. Per-outcome thinking is the right lens when you are buying a finished task from an agent vendor and do not want to underwrite their token efficiency. Many real products sit in between: a per-seat or per-month tier with usage-based (token or action) overage. The model you are quoted tells you who bears the efficiency risk.
The conversion that makes them comparable
Whatever the billing model, convert every quote to dollars-per-completed-outcome before comparing. For a per-token plan, that means estimating tokens-per-outcome (input plus output) and multiplying by the published token rate; for a per-outcome plan, the number is already in the right unit. Only after this conversion can a token-priced build and an outcome-priced vendor be weighed against each other — and against the human-labor baseline for the same task.
This is exactly why the WorkForce Labor Index is defined per task. A per-outcome unit is the only one that survives across the model layer and the agent layer, which is what a benchmark needs.
What it means for buyers
If you are buying a finished outcome, prefer per-outcome pricing or convert per-token quotes into it before you compare — and never compare a raw per-token rate to a per-outcome rate directly. Then put a quality number beside the price: a higher per-outcome price is only justified by a measurably higher quality score with a confidence interval. Cheap tokens that produce low-quality outcomes are not cheap once rework is counted.
Methodology note
This article describes pricing models conceptually and references vendor and model-provider pricing only as the model type (per token, per resolution, usage-based) without stating any specific figure as a market rate. The WLI publishes a per-task rate with its confidence interval and sample size once transaction coverage exists; see /methodology for how the index is calculated and governed.
Next steps
Get a free, independent quality score at /eval, and track the live per-task rates at /wli as categories cross the publication threshold.