AI cost per accepted result: beyond token prices

The price of a model call matters. The cost of getting a useful result through a complete workflow matters more.

At a glance

Divide the full workflow cost, including model calls, tools, retries and human review, by the number of results that pass a defined review standard. Cheaper requests do not automatically mean cheaper accepted results. The property-research example below is a proposed test, not a reported company result.

When an AI provider lowers its price, a team can afford to test more ideas. But a cheaper call does not automatically make a product cheaper to operate. The workflow may still need repeated calls, other tools, and a person to check the output.

How do you calculate cost per accepted result?

I would start with a simple measure:

Cost per accepted result = total workflow cost ÷ results that pass review.

The numerator includes model input and output, cached context, tool calls, retries, failed runs, and human review time. The denominator counts outputs that meet a defined standard for the task. A low price per request can still produce an expensive result when many requests fail or need extensive correction.

If no output passes review, report the experiment’s total spend and zero accepted outputs separately. Cost per accepted result is undefined for that run; do not report it as zero or infinity.

Compare workflows only for the same defined task and acceptance criterion, and include the relevant cost categories consistently. Read cost per accepted result alongside precision, recall and time to a decision; a lower cost figure alone does not show that the workflow is more useful.

This is a measurement framework, not a universal benchmark. Teams need to define what “accepted” means for their own workflow and record the assumptions behind any cost comparison.

How does this connect to my work?

At Appraiva, I work on connecting property imagery analysis with property identity, data enrichment and search. The property-research test in this article is a proposed experiment, not a description of an Appraiva feature or a reported company result.

How would you test a property-research workflow?

Imagine testing a tool that flags property records for further investigation. Start with a human-labeled set of records. Ask the system to surface candidates with supporting evidence. Have a reviewer accept or reject each suggestion, then measure precision, recall, total cost, and time to a decision.

That is a proposed experiment, not a description of an Appraiva feature or a reported company result. It illustrates why a model that is cheaper to call might still cost more per accepted candidate if it sends too many false leads to a reviewer.

What would I test first?

• Choose one repetitive task and write down the current human process.

• Define a clear acceptance rule before running the AI test.

• Track model, tool, retry and review costs for every attempt.

• Compare accepted results and time to decision against the current process.

The useful question is whether the workflow helps someone reach a reliable decision at a cost that makes sense. Lower model prices make that test easier to run; they do not answer it by themselves.

This is an evergreen excerpt of my published article. The dated provider-price announcement is omitted. AI prepared this syndication from the published text; no new company result or measured experiment is claimed.

Measure cost per accepted result

Divide all recorded workflow costs by the number of distinct results accepted under a rule fixed before the test. Include retries and rejected attempts in cost; do not count repeated attempts as new accepted results.

All attempt costs → Acceptance rule → Cost per accepted result

Total recorded cost ÷ distinct accepted results. With none accepted, unit cost is undefined.

This guide uses “accepted result” for an output that passes the recorded review rule. “Verified result” in the historical URL and earlier title refers to that same rule; neither term establishes independent certification. Keep unknown costs separate from explicit zero. Compare the same intended result batch and currency, and report acceptance counts alongside unit cost. A lower unit cost with a weaker acceptance rule is not a like-for-like improvement.

Decision checklist

• Freeze the task, intended result IDs and acceptance rule.
• Record model, tool, labor and other costs consistently for all attempts.
• Retain rejected attempts and retries in the numerator.
• Count each accepted result once; report unknown cost inputs as unknown.
• If no result is accepted, report total spend and zero accepted results, with unit cost undefined.

Full guide · Signature ideas · Related tool

Further reading

• Holistic Evaluation of Language Models (2022)
• NIST AI RMF 1.0
• AI workflow cost ledger: source and measurement limits

These references inform the evaluation and interaction principles. The workflow above is an editorial synthesis, not an endorsed standard or a reported company outcome.