How to Calculate Cost per Successful AI Task

Direct answer. Cost per successful AI task equals the fully loaded cost of a workflow divided by the number of tasks that meet its agreed success standard. Fully loaded means model calls, retries, abandoned runs, tools, retrieval, infrastructure, and any required human review - not just input and output tokens.

Last reviewed: July 15, 2026. Use this measure for a stable workflow with an explicit success definition. Do not use it to make a universal claim about an entire AI program.

Token cost answers a narrow engineering question. A FinOps or product decision needs a broader one: what did it cost to produce a result that actually worked? A workflow that has low per-call spend but a high retry rate or mandatory 15-minute review may be more expensive than a higher-priced model that gets the job done reliably.

Define success before the formula

Write one sentence that a product owner, operator, and quality reviewer can all accept. Good definitions describe the unit of work and the guardrail.

If the workflow has multiple outcomes, report them separately. Combining easy and hard task types can hide a cost or quality regression.

The core formulas

Fully loaded workflow cost can be modeled as:

Use effective rather than list cost where discounts, credits, or commitments are material. Use the AI cost allocation template to ensure shared platform cost does not disappear from the calculation.

Worked example: support resolution

In one month, an AI support workflow receives 10,000 attempts. It records $6,000 in model and tool charges, $1,000 in retrieval and infrastructure, and $3,000 in required review. It resolves 7,500 tickets without re-open.

Now compare a lower-cost model that reduces model and tool charges to $4,500 but drops success to 6,000 and raises review cost to $4,000. Fully loaded cost is $9,500, but cost per successful task is $1.58. The apparent $500 saving is a worse operating result.

Three patterns worth measuring

1. Document processing

Count documents that pass required-field validation and the defined review policy. Include OCR, extraction, model, retrieval, exception queue, and reviewer cost. Do not treat an output as successful solely because a JSON response existed.

2. Coding workflows

Use a stable task class such as issues closed, reviewed pull requests merged, or test-approved change requests. Include seat cost or usage credits, cloud-agent usage, CI, and any normal review time that changed because of the tool. Lines of code are an activity metric, not an outcome metric.

3. Employee copilots

Cost per active user can be helpful, but add an adoption and outcome layer. A monthly seat may support a handful of high-value tasks rather than daily use. Define the role-specific recurring workflow and capture a lightweight quality or acceptance signal before identifying a seat as waste.

Track retries and abandonment explicitly

Retries are not noise. They are a spend driver and often a quality signal. For each attempt, preserve at least:

• workflow and task type
• initial or retry attempt number
• model and major tools used
• completion status and failure reason
• latency or timeout state
• reviewer decision when applicable
• estimated and effective cost

Then calculate retry waste:

Avoid calling all non-success cost waste. Some failures are deliberate safety blocks or useful evaluation cases. Label them so the optimization decision is accurate.

Run a before/after optimization test

Treat a model, prompt, cache, batch, routing, or agent-limit change as an experiment. Use this sequence:

1. Choose one workflow and success definition.
2. Establish a baseline for enough volume to represent normal work.
3. Set quality, latency, safety, and escalation guardrails before changing cost.
4. Change one material variable, or use a controlled split when practical.
5. Compare cost per successful task, success rate, review rate, and latency.
6. Document whether the result is stable enough to roll out, revert, or test again.

The recommendation should say more than "use the cheaper model." It should say: "For this task type, at this traffic level, the change lowered cost per successful task from $X to $Y while success stayed above Z and review did not increase."

Common measurement mistakes

• Counting every completed request as a success.
• Ignoring human review because it is paid from another budget.
• Comparing a pilot's best week to a production baseline.
• Using blended provider cost for workflows with different quality requirements.
• Removing a quality check to make an optimization chart look better.
• Reporting a precise unit cost when shared infrastructure is still unallocated.

For a full cost view, start with what to track beyond tokens. Then use LLM observability vs AI spend management to decide where trace data belongs in your operating model.

Sources

• FinOps Foundation: FinOps for AI
• FOCUS specification: unit cost and allocation use cases
• Langfuse metrics overview