AI cost per successful task: formula, measurement and worked example
Use this calculation:
AI cost per successful task = all attributable workflow costs ÷ the number of tasks that meet predefined acceptance criteria.
The numerator includes model calls, tools, failed attempts, infrastructure, human review and ongoing operations. The denominator counts business-accepted results. If no task succeeds, the metric is undefined; report the incurred cost and lack of successful outcomes explicitly.
A more expensive model can be more economical if it requires fewer retries and human corrections. Whether that holds for your workflow must be measured.
A request, an AI run and a completed task are different units
| Metric | What it measures | Appropriate use |
|---|---|---|
| API cost per call | Cost of one model request | Technical consumption analysis |
| Cost per automatically accepted AI result | Total defined cost base divided by automatically accepted tasks | Economic comparison with an explicit scope |
| Cost per completed business transaction | Total process costs divided by all completed transactions | Business case including review and fallback |
A business task may contain several model calls. An agent might research, retrieve a document, call a tool, validate the result and start again after a failure. Five successful API calls still produce only one completed task.
A technically successful HTTP request does not establish business success. If the result must be rebuilt manually, the AI task was not automatically successful.
Define success before testing
For structured document review, a successful task might require:
- all mandatory fields are captured,
- values and data types are valid,
- relevant amounts satisfy defined validation rules,
- source and document version are traceable,
- no prohibited action was performed,
- the result is accepted without substantive correction.
Agents also need execution criteria: correct tools, valid parameters, respected approvals and correct state changes. AI agent evaluation explains how to assess these paths.
A practical outcome model has four states:
- Automatically accepted: all criteria are met without human changes.
- Corrected after review: a person makes substantive changes.
- Manual fallback: the AI task fails and the transaction is completed another way.
- Incomplete: no accepted result is available.
A corrected result may complete a business transaction, but should not count as fully automatic AI success. Report both metrics with a named cost base: per automatically accepted result and per completed business transaction.
What belongs in the cost base
Models and inference
Capture input, output and any separately billed token categories, cache usage, embeddings, additional model calls, retries and model fallbacks.
The official OpenAI price list includes separate tool and container charges alongside model prices. A single token price therefore cannot represent the entire bill. Source checked on 22 October 2026.
Version the price table with provider, model, processing tier, currency and effective date. Replace estimates with actual billed costs where they can be attributed.
Tools and external services
Depending on the workflow, costs may include search, OCR, document parsing, databases, vector search, business APIs, code execution, storage and data transfer.
Assign each step to the original task. Separate model-call bills cannot explain the total cost of the transaction.
Infrastructure and operations
An API-based solution still needs an application, data storage, queues, logging and monitoring. Self-hosted models also require reserved and unused compute capacity, updates and operational ownership.
An API-versus-self-hosting comparison needs the same task and quality threshold. Private AI vs public cloud covers the architectural trade-offs.
Human review and correction
Measure review time, substantive corrections, clarification requests, manual entry, escalations and complete manual replacement. A quick approval and a substantial reconstruction must not receive the same effort estimate.
For planning, measured minutes can be valued using an explicitly stated internal hourly rate. That rate is a costing assumption, not automatically an additional cash expense.
Ongoing quality assurance
Include allocated evaluation effort, sampling, failure analysis, test-case maintenance and necessary adaptations to model or provider changes.
Show one-off development costs separately. A business case may amortise them over a clearly defined period or expected task volume. Allocate shared platform costs consistently across alternatives and avoid double counting.
A minimal measurement schema per task
Connect every model and tool call to the business outcome of the same task. A small schema is sufficient to start:
| Field | Purpose |
|---|---|
workflow_name | Stable name of the business task |
task_id | Connects all calls to one transaction |
attempt_id | Distinguishes first attempt, retry and fallback |
| Provider and model version | Makes alternatives comparable |
| Token categories and price version | Calculates model cost |
| Tool and tool cost | Captures search, OCR, APIs and execution |
outcome_status | Accepted automatically, corrected, fallback or incomplete |
failure_reason | Attributes cost to a failure class |
review_minutes | Captures human effort |
| Prompt, workflow and policy versions | Explains differences between runs |
This is a suggested application schema. It does not require indiscriminate logging of full content or personal data. Retain the evidence needed to connect cost and outcome reliably.
Fictional worked example: the more expensive model wins
This example is entirely fictional. It is neither a customer case nor a measured model benchmark. Two alternatives process the same 1,000 technical service transactions using identical acceptance criteria.
| Metric for the test period | Option A | Option B |
|---|---|---|
| Tasks processed | 1,000 | 1,000 |
| Automatically accepted | 760 | 860 |
| Completed after human correction | 170 | 100 |
| Completed manually | 50 | 30 |
| Incomplete | 20 | 10 |
| Model and tool costs | €160 | €320 |
| Platform and logging | €140 | €150 |
| Review, correction and manual fallback | €1,250 | €600 |
| Allocated evaluation and operations | €450 | €430 |
| Total cost | €2,000 | €1,500 |
Human effort includes all review, correction and manual fallback. At an assumed internal rate of €50 per hour, these amounts represent 25 and 12 hours respectively. Evaluation and operations are recorded separately and are not counted again in that line.
Option A:
- per task processed: €2,000 ÷ 1,000 = €2.00
- per automatically accepted result: €2,000 ÷ 760 = €2.63
- per completed business transaction: €2,000 ÷ 980 = €2.04
Option B:
- per task processed: €1,500 ÷ 1,000 = €1.50
- per automatically accepted result: €1,500 ÷ 860 = €1.74
- per completed business transaction: €1,500 ÷ 990 = €1.52
Total workflow cost per automatically accepted result is a measure of the burden carried by the whole workflow. It includes effort spent on cases that were not completed automatically. It is not the isolated production cost of the successful subset.
In this fictional example, total cost falls by 25%; cost per automatically accepted result falls by approximately 34%. Reduced rework outweighs higher model and tool costs.
A real decision must also assess security, quality and latency requirements. A cheaper average does not justify a critical failure.
Averages can hide expensive failure classes
Segment tasks by differences that matter in your workflow: document length, language, source, tool use or business exception.
Identify the groups causing repeated retries, long contexts or manual processing. A small but critical group can fail repeatedly while the average remains unremarkable.
Seven common calculation errors
- Counting every technically completed response as success.
- Treating corrected results as fully automatic.
- Analysing retries without linking them to the original task.
- Comparing tokens while excluding the rest of the workflow.
- Mixing development and recurring operations without a transparent allocation.
- Comparing alternatives with different cases or quality thresholds.
- Hiding critical failure classes inside an aggregate average.
Turn the metric into a go/no-go decision
First define one concrete task, acceptance criteria and critical failures. Test alternatives on the same representative cases. Capture every attempt and human processing step.
Set the economic limit before the test as well: how much can an accepted transaction cost for the workflow to be viable compared with the existing process?
Planning an AI pilot explains how to build a pilot around testable success criteria.
If an existing pilot works in principle but success rate, rework and cost cannot be connected reliably, I can help establish a measurable decision basis through the AI Production Readiness & Reliability Sprint.