Guide · AI workload economics
Why the cheapest LLM per request can cost more per result
Price per request tells you what an attempt costs. What a team pays for is a result. When a model fails more often, its low price is spread over fewer successes, and the cheapest model on a price sheet can become one of the most expensive per successful outcome.
The metric: cost per successful request
For one workload and one model, add up the cost of every request, including the ones that failed, and divide by the number of requests that succeeded.
cost per successful request = cost of all requests ÷ successful requests
Failed attempts are still billed. A retry is a second paid request. So the denominator is what changes the ranking: a model that succeeds on one request in ten carries the cost of the other nine.
A worked synthetic example
These figures come from the synthetic usage export AIYVO's analyzer is demonstrated on. The models are fictitious; the arithmetic is the point.
| Model | Succeeded | Per request | Per successful request |
|---|---|---|---|
| model-c1 | 20 of 200 | $0.0147 | $0.1474 |
| model-b1 | 149 of 200 | $0.0510 | $0.0684 |
| model-a1 | 173 of 200 | $0.1743 | $0.2015 |
Ranked by price per request, model-c1 is first. Ranked by cost per successful request, model-b1 is first and model-c1 drops to second: $0.14744 ÷ $0.06842 ≈ 2.15. That ratio is illustrative, between two synthetic models; it is not a measured outcome for any real provider.
What has to be true before you trust the number
- A success definition that fits the workload. “The request returned” is not success. Use the check your system already applies: a test passed, a field was extracted, a reviewer accepted the answer. Change the definition and the ranking can change with it.
- Enough records. AIYVO’s analyzer compares a model only with at least 30 records. Below that, it reports the model and withholds the comparison.
- No missing cost treated as zero. A record with no cost is excluded from cost metrics, not counted as free. Counting it as zero would make that model look cheaper than it is.
- The same workload on every model. Comparing a model on easy prompts with another on hard ones measures the prompts, not the models.
Requests are not always the unit that matters
An agent step, a retry and a fallback are each a request. A task is the whole job, and it succeeds or fails once. If your export has one row per request, you get cost per successful request; if it records whole tasks, you can compute cost per completed task, which adds up every request the task needed. The two answer different questions, so check which one your data supports before comparing models. The provider comparison checklist covers this in more detail.
Where the number stops
Cost per successful request says nothing about latency, data-handling terms or how good a successful answer is beyond your success check. It is one input to a model decision, and it is only as good as the success flag and cost fields in the export behind it.