Teaching scenario: Every dollar amount and outcome count below is hypothetical. These are arithmetic examples, not current model prices, benchmarks, or promised savings.
Define what success means firstA low-cost model call can still produce an expensive workflow if the answer needs repeated correction. Start by defining the task and its acceptance criteria. In this exercise, a support assistant must answer an eligible question using applicable evidence, satisfy an accuracy rubric, and complete within the agreed response window. An unsupported answer does not count as success merely because the API returned normally.
Choose a comparable set of tasks for two workflow variants. Keep the rubric and evaluation method consistent. If one variant receives simpler questions, its lower unit cost does not establish that the design is more efficient.
The FinOps Foundation's unit-economics guidance connects technology costs to units of business value. For an AI workflow, a quality-qualified completed task is one useful candidate unit. It needs an explicit definition and an owner who can verify the outcome. Primary reference: FinOps Unit Economics.
Include the costs of unsuccessful attemptsFor this example, compare 1,000 attempted tasks per variant. The cost boundary includes inference, retrieval, paid tools, additional retry activity, and allocated human review. Retry cost here contains only costs not already allocated to the other rows; otherwise the table would double-count them.
Hypothetical cost or result
Workflow A
Workflow B
Initial inference
$40
$70
Retrieval
$20
$15
Paid tools
$20
$15
Additional retry activity
$10
$10
Allocated human review
$60
$70
Total cost of all 1,000 attempts
$150
$180
Tasks meeting the same acceptance criteria
600
900
Cost per successful task is the total in-scope cost of all attempts divided by the number of accepted tasks in that same cohort. Workflow A is $150 / 600 = $0.25. Workflow B is $180 / 900 = $0.20. B has a higher total cost in this example, but a lower cost per accepted task. That conclusion follows from the stated numbers; it says nothing about an untested model or workload.
If zero tasks meet the criteria, report that there were no successful tasks and that the ratio is undefined. Reporting zero cost per success would reverse the meaning of the result.
Keep the denominator honestCount one completed business task once, even if it used several model calls. Keep unknown outcomes separate until they can be evaluated. Do not remove difficult failures from the cohort merely because they make the metric worse. If exclusions are necessary, state the rule before comparing variants.
Also report success rate: 60 percent for A and 90 percent for B in this example. Include latency and relevant failure categories. Two workflows can have the same cost per success while providing very different experiences. One may meet the average cost target but miss the response window on the tasks users care about most.
Make the allocation explicitThis simple calculation excludes one-time development cost, shared platform overhead, and other costs outside the declared boundary. A production review may need them. Choose an allocation method, state it, and apply it consistently. Use the same currency and reporting period, and distinguish measured invoices from estimates.
Separate the effects of volume, task mix, provider price changes, and architecture changes. An increase in total spend can accompany useful growth, while a falling average can hide a shift toward easier tasks. The comparison needs enough context to explain either result.
Practice the decisionFor an interview: Show the arithmetic, define success, and explain why token price alone cannot choose the workflow. For a team: Select a representative evaluation cohort, agree on acceptance criteria, and compare one proposed change. For example, test a simpler retrieval path before replacing the model. Keep the change only if its cost improvement preserves the required quality and response behavior.
Teaching scenario: Every dollar amount and outcome count below is hypothetical. These are arithmetic examples, not current model prices, benchmarks, or promised savings.
Define what success means firstA low-cost model call can still produce an expensive workflow if the answer needs repeated correction. Start by defining the task and its acceptance criteria. In this exercise, a support assistant must answer an eligible question using applicable evidence, satisfy an accuracy rubric, and complete within the agreed response window. An unsupported answer does not count as success merely because the API returned normally.
Choose a comparable set of tasks for two workflow variants. Keep the rubric and evaluation method consistent. If one variant receives simpler questions, its lower unit cost does not establish that the design is more efficient.
The FinOps Foundation's unit-economics guidance connects technology costs to units of business value. For an AI workflow, a quality-qualified completed task is one useful candidate unit. It needs an explicit definition and an owner who can verify the outcome. Primary reference: FinOps Unit Economics.
Include the costs of unsuccessful attemptsFor this example, compare 1,000 attempted tasks per variant. The cost boundary includes inference, retrieval, paid tools, additional retry activity, and allocated human review. Retry cost here contains only costs not already allocated to the other rows; otherwise the table would double-count them.
Hypothetical cost or result
Workflow A
Workflow B
Initial inference
$40
$70
Retrieval
$20
$15
Paid tools
$20
$15
Additional retry activity
$10
$10
Allocated human review
$60
$70
Total cost of all 1,000 attempts
$150
$180
Tasks meeting the same acceptance criteria
600
900
Cost per successful task is the total in-scope cost of all attempts divided by the number of accepted tasks in that same cohort. Workflow A is $150 / 600 = $0.25. Workflow B is $180 / 900 = $0.20. B has a higher total cost in this example, but a lower cost per accepted task. That conclusion follows from the stated numbers; it says nothing about an untested model or workload.
If zero tasks meet the criteria, report that there were no successful tasks and that the ratio is undefined. Reporting zero cost per success would reverse the meaning of the result.
Keep the denominator honestCount one completed business task once, even if it used several model calls. Keep unknown outcomes separate until they can be evaluated. Do not remove difficult failures from the cohort merely because they make the metric worse. If exclusions are necessary, state the rule before comparing variants.
Also report success rate: 60 percent for A and 90 percent for B in this example. Include latency and relevant failure categories. Two workflows can have the same cost per success while providing very different experiences. One may meet the average cost target but miss the response window on the tasks users care about most.
Make the allocation explicitThis simple calculation excludes one-time development cost, shared platform overhead, and other costs outside the declared boundary. A production review may need them. Choose an allocation method, state it, and apply it consistently. Use the same currency and reporting period, and distinguish measured invoices from estimates.
Separate the effects of volume, task mix, provider price changes, and architecture changes. An increase in total spend can accompany useful growth, while a falling average can hide a shift toward easier tasks. The comparison needs enough context to explain either result.
Practice the decisionFor an interview: Show the arithmetic, define success, and explain why token price alone cannot choose the workflow. For a team: Select a representative evaluation cohort, agree on acceptance criteria, and compare one proposed change. For example, test a simpler retrieval path before replacing the model. Keep the change only if its cost improvement preserves the required quality and response behavior.