Cost per successful AI-assisted task includes the cost of getting work accepted, including unsuccessful attempts, retries, preparation, checking, correction and support. Add the relevant technology and people costs for a defined set of work, then divide by its accepted results. State the currency, period and cost boundary alongside the number.
For a department lead and finance partner, the useful question is whether that calculation describes the work they intend to fund. A low model bill can sit beside a substantial review commitment. A high cost during setup can also describe a different decision from the recurring cost of running the task.
Define the result before dividing the cost
An AI response is not automatically a completed business task. Define the output and the check that makes it usable before counting successes. The FinOps Foundation's unit-economics guidance distinguishes technical consumption measures from business outcomes and emphasizes explicit scope and assumptions.
Suppose Sam Taylor manages product descriptions for a clothing retailer. His team uses AI to draft descriptions from approved manufacturer specifications and garment care labels. An editor must confirm the correct item, supported fabric and care claims, and the retailer's format before accepting a description as ready to publish. Generating a plausible paragraph does not meet that standard.
Give each product description one case identifier. Keep its attempts, review and final disposition together. Three drafts of the same description are still one case. The net-time measurement guide explains how to count human effort across attempts without losing failed work.
For Sam's calculation, the unit is an editor-accepted product description, not a model call, a draft or a published listing. Publishing remains a separate action outside this task's boundary.
Reconcile one batch from spend to accepted work
Suppose the team processes 100 product cases in one week. By the agreed cutoff, the editor has accepted 80 descriptions and 20 remain unaccepted. The workflow made 135 model and tool calls, including retries. Use the same batch of cases for the cost record and the acceptance count.
The following amounts are assumptions for this example, in US dollars. The staff and support hours cover all 100 cases, including the unsuccessful work. Software and infrastructure are assigned once to this batch under an agreed allocation policy.
| Cost included | Basis for this batch | Amount |
|---|---|---|
Model and tool usage | All attempts, including retries and failed cases | $40 |
Software and infrastructure | The batch's allocated share, excluding usage already above | $80 |
Preparation, prompting, review and correction | 13 staff hours at an assumed $30 per hour | $390 |
Separate technical support | 2 hours at an assumed $40 per hour | $80 |
Total resources valued in dollars | Technology plus staff work and separate support | $590 |
Two calculations answer different questions:
- Technology cost per accepted description is $1.50. The $120 of usage and allocated software and infrastructure divided by 80 accepted descriptions measures this technology cost boundary.
- Resource cost per accepted description is $7.38. The $590 total divided by the same 80 accepted descriptions includes the valued staff and support effort, rounded to cents.
Neither number is a saving. The broader figure values resources consumed; it does not mean the retailer paid $590 of additional cash. Existing employees' time is already in payroll, and the allocated software share may come from an existing commitment. The adoption budget guide explains how to keep cash requirements and staff commitments distinct.
The 20 unaccepted cases have not disappeared. Their costs are in the numerator, but they supply no accepted descriptions at this cutoff. Do not divide by all 100 cases and label the result a cost per success. Equally, the 135 calls belong in a technical usage measure, not the business-output count.
Include the work around the model
Review may fall to someone other than the person using AI. In a May 2026 Reddit discussion, a Reddit user on a small development team described manually reviewing a colleague's AI-generated code changes, then receiving lengthy AI-written replies. In the discussion, they clarified that the replies could make sense and some requested changes were accepted. Their frustration concerned the ownership and review effort around the changes.
That account supplies no measured cost or general failure rate. It does make the accounting question concrete: whose time disappears when only the person producing the draft records their work? For Sam's catalog team, the editor's checking belongs in the cost even if drafting happens quickly.
OpenAI's July 2026 scorecard similarly argues for including employee time, review, retries and rework when evaluating task cost. This is a vendor's proposed evaluation approach, rather than independent evidence that a particular model or workflow costs less.
Keep the boundary practical and traceable:
- Count direct work once. Include preparation, checking and corrections, with the rate and hours visible. Do not add the same support hour again under a second team.
- Show shared costs separately. Explain how software, infrastructure or monitoring was assigned. An allocated share and an additional bill answer different questions.
- Identify setup treatment. Sam's recurring-batch figures exclude initial integration and training. Show those costs separately, or state the period and volume used to allocate them before describing a broader total.
- Leave important unknowns visible. If support effort or an external service charge is missing, label the estimate incomplete and name who will resolve it.
The FinOps Foundation's allocation guidance allows different shared-cost approaches, including an explicit decision to fund some costs centrally. Choose a policy with finance that fits the decision. A complicated allocation is not automatically more accurate, and centrally funded work is not costless.
Keep unfinished work and manual recovery visible
A cutoff creates a reporting boundary, not a verdict on every case. If Sam's remaining 20 descriptions are accepted later, update their costs and outcomes together. Do not add those acceptances to the earlier denominator while leaving their later review costs out.
For continuing operations, distinguish a calendar-period report from a followed batch. A month's bill and that month's acceptances can describe current operations, but they may cover different cases when work crosses months. Show opening and closing unfinished work, or follow a defined batch through completion before comparing its cost with another batch. Mark provisional results clearly.
Manual recovery needs an equally explicit label. If an editor rewrites a failed AI draft and finishes the description, it may count as an accepted result of the whole assisted workflow when that is the agreed boundary. Include the failed AI work and the manual rewrite. It cannot count as an autonomous AI success. Record how many accepted results required that recovery so the aggregate does not conceal it.
Use unit cost to ask the next question
Compare costs only when the output, acceptance check, work mix and cost boundary are comparable. An easier batch, less checking or excluded staff time can lower the reported figure without improving the workflow. Keep acceptance rate, unfinished volume and important defects beside the unit cost.
For Sam, a useful next step is to take the batch record to the editor and finance partner. Confirm that the acceptance count is correct, no work is missing, and shared costs were assigned once. Then compare the same finished task under the existing process or another approved approach.
The business-case guide covers whether those differences justify funding and how benefits could become usable capacity or cash. Return to the measuring AI value guide for the wider evidence needed. Cost per accepted result helps explain the resources required. The value of the result still needs its own evidence.
Questions about cost per successful AI-assisted task
Should failed attempts and retries be included?
Yes. Include the relevant costs of every attempt in the defined set of work, including cases that never produce an accepted result. Count each accepted business result once. In the catalog example, 135 calls support 100 cases, of which 80 are accepted at the cutoff. Dividing the full batch cost by 80 preserves the cost of unsuccessful work.
Should we include salaries if payroll does not change?
Include an explicit valuation of staff effort when comparing the resources needed to complete work. Keep that calculation separate from additional cash spending. State the hours and the rate agreed with finance; do not describe valued time as a payroll saving. The cash and staff budget guidance explains how those views support different decisions.
Is an existing AI subscription free for this calculation?
An existing subscription may add no new charge for the next task, while still carrying a cost assigned to the workflow. State whether the calculation measures additional spending or includes an allocated share of existing commitments. Keep that treatment consistent across the options being compared, and explain any excluded central funding. Avoid adding allocated usage again when it is already counted directly.
What if no AI-assisted tasks are accepted?
Cost per accepted task is undefined when the accepted count is zero. Report the spend, attempts, unfinished or rejected cases, and the acceptance conditions instead of showing a zero unit cost. Investigate why the work was not accepted before using the calculation to support expansion. A task can incur substantial cost while producing no usable result.
Does a lower cost per accepted task prove positive ROI?
No. A lower unit cost describes a resource comparison within its stated boundary. Positive return also requires evidence about the value delivered, relevant alternatives and the costs of making the change. Check equivalent quality and work mix first, then use the business-case approach to examine which benefits can actually be realized.
