Cost per Completed Task: The AI Metric That Survives a CFO Review

Why does cost per token fail a finance review?

Because nobody buys tokens. They buy finished work: quotes issued, invoices posted, tickets closed, cases resolved. A token price is an input that moves with prompt length, context strategy and retries — and it can fall while the cost of finishing the same work rises.

Here is the failure in one line. A cheaper model that abstains more often, or that fails validation and retries, can reduce cost per token and increase cost per completed task, because the denominator shrank and the human queue grew. Nobody in the room notices, because the metric everyone is watching improved.

The number that survives a finance review is fully loaded cost per successfully completed task: every attempt, every retry, every minute of human review, divided by the tasks that actually completed — with the denominator stated out loud.

I have built this number for workflows where the model cost is a rounding error and the review time is the entire budget, and I have also watched a proposal die because the only figure in it was a per-token estimate. The second outcome is avoidable with one afternoon of logging.

What has to be logged to compute it?

The number is only as good as the run record, and the record has to distinguish four outcomes rather than two. "Completed" and "failed" is not enough; abstention and duplication are where the money hides.

Two properties make this table work. It is keyed by task, so a retried task cannot inflate the count of finished work. And it records who reviewed what, so the human line is attributable rather than estimated.

What is the formula?

cost_per_completed_task =
    ( Σ inference and orchestration cost of every attempt
    + Σ human review minutes × loaded rate
    + amortised platform and gateway fees for the period
    + cost of failed-write cleanup, where it exists )
    ÷ number of tasks that reached "completed"

Four ways this is usually miscalculated, and each of them flatters the system:

1. Retries excluded. Counting only successful attempts removes the retry tax, which on validation-heavy workflows I have scoped is between ten and forty per cent of inference cost.
2. Abstentions counted as completions. A system that hands work to a person has not completed it; it has correctly declined to. That is a good behaviour and a bad denominator.
3. Review minutes omitted. The workflow did not remove the human step; it moved it. If the minutes are not in the numerator, the model is being compared against a fantasy.
4. Fees amortised over promised volume. A platform fee divided by the volume in the sales deck rather than the volume in the logs produces a number that improves every month for no operational reason.

What does the number look like with real inputs?

Here is the structure with placeholders, because the inputs are yours and I do not publish mine as benchmarks. The arithmetic is the point; substitute your figures and it works.

That produces a human line of roughly [504 × 6 ÷ 60 × $62 ≈ $3,125] against an inference line of roughly [4,200 × 1.15 × $0.02 ≈ $97]. The tail is more than thirty times the model cost, and the ratio is the finding rather than the amounts: whatever your numbers are, the review line is where the budget lives, and it is the line a per-token metric cannot see.

The second thing this structure gives you is sensitivity. If abstention rises from twelve to twenty per cent because a model update made the system more cautious — a change most teams would describe as an improvement in safety — the human line goes to about [$5,208] and cost per completed task rises by roughly two thirds. That is the conversation to have with the person who owns the budget, and it is only available if the three buckets have been logged separately.

What does this number tell you that accuracy does not?

It prices the failure modes. Accuracy tells you how often the system is right; cost per completed task tells you what the wrong cases and the declined cases cost, which is the quantity that decides whether the workflow should exist.

It locates the break-even volume. Below some volume the fixed human line dominates and no model price saves the business case; above it the relationship flips. You cannot find that point from a token price.

It exposes the retry tax. Attempts per task is invisible in most dashboards and is the cheapest thing to reduce — usually by tightening a schema until validation rejects bad input before a model call happens.

It makes vendor quotes comparable. A platform's per-run price is only comparable once you know it is inclusive of retries and failures. That is a written question for procurement, and the questions vendors answer least well are the ones about which cost lines are theirs.

How do you compare a bought per-run price with your own number?

Compute both at your current volume and at three and ten times current volume, because the lines scale differently: inference scales with attempts, human review scales with abstentions, and platform fees scale on whatever schedule the contract chose.

Doing this arithmetic properly is the whole of whether it is cheaper to build or buy, and the unit it produces is exactly the one above. If the process is valuable enough to own, the boundary work is what makes the number fall; if it is not, the number is what tells you to buy something cheap and move on.

What numbers can you not get?

Three, and no amount of logging produces them:

• The loaded rate of a reviewer, unless payroll gives you the fully loaded figure rather than the salary. Ask for the fully loaded number; the difference is usually twenty to forty per cent.
• The amortised platform fee at your actual volume, unless the contract meters something. A flat fee at unknown volume is a range, and a range is honest.
• The value of a completed task, which is the only thing that turns a cost into a return. That figure belongs to the process owner, not to the system.

The model is built to work with ranges on all three, because a number with a stated range and a stated denominator is a decision-making instrument, and a single figure with neither is a slide.

The one-line version for the board

"Fully loaded cost per completed task, at current volume, with the denominator stated — and here is what it becomes if abstention doubles."

That sentence carries the metric, the scope and the risk in one line, which is why it survives the room. Everything else in this article is the work behind it: four outcome states, attempts per task, review minutes, and the discipline to divide by finished work rather than by effort spent. If you want the sibling metric for the inference layer alone — the per-token model that finance will accept as an input rather than an answer — the token cost model for business processes is the one to build alongside it.