Ahmadreza Samadi / HomeAnalysis · AI product economics
AI cost per verified result
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.
What changed in September 2026?
On 22 September, OpenAI announced that GPT-6 Sol and Luna API prices were 50% lower than their GPT-5.6 promotional prices. Anthropic announced lower prices for Claude Opus 5.5 and estimated about 40% lower cost for typical token-billed work than Opus 5. The providers use different baselines, so these percentages do not compare their models with each other.
For a business, the opportunity is to retest tasks that were too expensive before. The decision still depends on quality, the amount of review required, and the cost of the whole process.
How do you calculate cost per verified result?
I would start with a simple measure:
Cost per verified 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.
This is a measurement framework, not a universal benchmark. Teams need to define what “verified” 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.
Continue the discussion
New: how an AI decision model like Jev changes the cost per accepted decision, and what to check before giving an assistant access to your apps.
I covered the same idea in an eight-page LinkedIn document for product and engineering teams and a plain-language Instagram carousel. For the broader product approach, read Start with the decision, then build the AI or use the interactive decision brief.