Divide the full cost of the work by the number of outputs that pass a clear review.
Cheap output can be expensive work
An AI request can cost very little and still create an expensive task. Someone has to read the result, find the unsupported claim, correct the formatting, rerun the request, and check the second attempt. If you compare only the service bill, that work disappears from the decision.
A more useful measure is cost per accepted result. Define what an acceptable output must do, count all the attempts needed to get there, and include the review effort. This does not replace quality judgment. It makes the cost of meeting the quality requirement easier to see.
Use it for a specific task. A usable support draft, a checked product description, and a working code change have different acceptance rules. Mixing them into one number can hide the very problem you are trying to understand.
Define the denominator first
An accepted result is an output that passes the agreed review. It is not simply a completed generation. If the answer is fast and well written but contains an unsupported product claim, it has not met the requirements of a factual product description.
Decide how to handle repaired outputs. You can accept them after correction, as long as the repair time is counted. Record first-pass acceptance separately if it matters. That helps distinguish a system that delivers useful work immediately from one that depends on an editor to finish every item.
Avoid moving the acceptance threshold after seeing the cost. If the cheaper workflow gets a more forgiving review, the comparison stops answering the original question.
Include the costs you actually incur
Start with service charges across all attempts, including failed runs and retries. Add the cost of required tools or external processing where relevant. Then record human review and repair time. If you convert that time to money, state the hourly rate and treat it as an assumption unless it comes from your own cost accounting.
Keep setup work visible. Designing the prompt, writing an integration, preparing a document set, and maintaining a review pack can be significant. You may spread that work across an expected volume, but show the volume assumption. A setup that is economical at ten thousand items can be a poor fit for fifty.
The basic calculation is total included cost divided by accepted results. If there are no accepted results, the cost per accepted result is undefined. Display that honestly rather than returning zero or a reassuring-looking average.
Work through a comparison
Consider two fictional workflows, each attempting the same twenty tasks under the same review rules. The hourly review rate is an illustrative $60. These are invented inputs to show the arithmetic, not results for any named model.
| Measure | Workflow A | Workflow B |
|---|---|---|
| Tasks attempted | 20 | 20 |
| Results accepted after review | 16 | 18 |
| Service cost across attempts | $4 | $9 |
| Total review and repair time | 60 minutes | 30 minutes |
| Included cost | $64 | $39 |
| Cost per accepted result | $4.00 | $2.17 |
Workflow B has a higher service bill and a lower included cost per accepted result. The difference comes from review effort. If review time were free for this decision, the result would change: the service-only costs are $0.25 and $0.50 per accepted result. State which boundary matters instead of pretending one number answers every situation.
Also inspect the failures. If Workflow B’s two failures are more serious than Workflow A’s four, the average cost cannot settle the choice. Critical errors need their own treatment.
Compare similar conditions
Use the same task pack, source material, and acceptance criteria. Record model versions, settings, tools, and time limits. If a workflow gets more retries, include them. If a reviewer already knows one system’s quirks, consider how that familiarity affects the time measurement.
Do not overinterpret a small pilot. A handful of tasks can help you identify obvious tradeoffs, but the mix may not represent a month of production. Repeat the important cases and review a broader sample before using the result to justify a large operational change.
Report the components alongside the ratio: attempted tasks, accepted results, direct cost, review minutes, and critical failures. That lets another person see whether an apparent improvement came from better output, cheaper service, or a different review process.
Use the number to find the next improvement
If review dominates cost, improve the evidence format or narrow the task. If retries dominate, examine the failure categories. If setup dominates at low volume, a simpler manual process may be the right answer. The calculation should direct attention to a specific part of the workflow.
The model-comparison worksheet calculates these measures from your own inputs. It starts with the fictional example above and lets you replace it. It does not send requests to a model, judge outputs, or infer a winner from a tiny sample.
The aim is ordinary cost discipline applied to AI work. Count what the team must do to get a result it can use, keep serious failures visible, and choose the workflow that fits the actual task.
About this article
Prepared by JDGMNT Editorial on 24 October 2026. Worked examples are illustrative; they are not campaign results or product benchmarks. The artwork was generated for this collection.