A model invoice is unusually precise about the least interesting part of an operating decision. It can tell you what was charged for tokens, calls, or provisioned capacity. It cannot tell you whether the resulting work was accepted, how many attempts disappeared on the way, or which person spent Friday afternoon repairing it.

Last week’s argument used accepted work as the common unit for comparing production routes. This week asks what it actually costs. The first step is simple and inconvenient: put the denominator before the bill.

If the business needs 800 accepted case summaries, the unit is not a request, a generated summary, or a successful HTTP response. It is one summary that meets the declared acceptance standard. Everything consumed in producing those 800 outcomes belongs somewhere in the account, including the work that failed.

Start with a reconciliation, not a rate card

Consider an explicitly illustrative month. A team submits 1,000 cases. The system produces 960 outputs. Review accepts 760 on the first pass; 140 pass after repair; 60 remain unresolved at the accounting cut-off. The business has 900 accepted outcomes, not 1,000 successful tasks.

The production account should reconcile those states:

  1. Production: model calls, retrieval, tools, orchestration, storage, and the people operating them.
  2. Verification: automated evaluation, human review, and the expert attention needed for consequential exceptions.
  3. Rework and recovery: retries, repairs, incident handling, and reruns after a dependency fails.
  4. Committed support: reserved capacity, licences, integration, evaluation maintenance, and other costs paid whether this month’s volume arrives or not.
  5. Unresolved work: failed, abandoned, or still-pending cases that consumed resources without entering the accepted denominator.

The last category is where attractive economics often go to disappear. Deleting unresolved cases from both the numerator and the denominator does not make a system efficient. It makes the account incomplete.

A layered accepted-work cost account includes production, verification, rework and recovery, committed support, and the allocated cost of unresolved work.
A proposed cost decomposition. The layers are categories, not measured proportions; every amount should reconcile to a declared population and period.

Suppose those categories total €18,000 for the illustrative month. Cost per accepted outcome is €20: €18,000 divided by 900. Dividing only a €3,600 model bill by the 1,000 submitted cases would produce €3.60. Both divisions are arithmetically correct. Only one answers what the business spent to obtain an accepted result under this accounting boundary.

The €20 is still not a universal truth. Change the time window, allocation rule, or acceptance standard and it will move. Its usefulness comes from making those choices inspectable.

Commitments need an allocation rule

Fixed and committed costs do not become zero when a dashboard has no obvious row to receive them. The FinOps Open Cost and Usage Specification, version 1.3, ratified on 5 December 2025, defines fields that distinguish billed cost, effective cost, and commitment-related status across technology billing data. Its discount-handling specification explicitly treats unused commitment as economically relevant: unused amounts can reduce or eliminate the expected saving.

That standard is designed to normalize billing records, not to calculate AI business value. Its contribution here is narrower and useful. It prevents a commitment from vanishing merely because no individual task consumed it. The operating account still needs a stated allocation method: by available capacity, active time, accepted volume, or another defensible driver.

A team can reasonably maintain reserve capacity for recovery and deliberately leave some of it idle. That is not necessarily waste. It is a continuity premium. Call it that, price it, and test whether the protected consequence merits the premium. Labelling it “free capacity” would be more soothing and less accurate.

Operator time is not miscellaneous

Human work is often entered as a footnote because it is hard to meter. Yet a system that shifts ten minutes from a junior operator to twenty minutes from a scarce reviewer may lower visible compute cost while making the operation worse.

Record time by activity and role, not merely by headcount. Task preparation, ordinary review, exception handling, incident recovery, evaluation upkeep, and supplier management have different constraints. An hour from a scarce domain expert has an opportunity cost even when payroll does not change that month.

This does not require theatrical precision. A sampled time study with an honest error range can be more useful than a decimal-rich estimate assembled from memory. The important discipline is to keep scarce attention inside the production account.

Cost follows the acceptance contract

The NIST AI Risk Management Framework core organizes work around governing, mapping, measuring, and managing risk across a system’s context. It does not prescribe a single acceptance threshold or cost formula. That limitation matters. A cost comparison cannot be separated from the conditions under which the work may be used.

For a low-consequence drafting aid, a quick human glance may be sufficient. For an action that can deny a benefit, change a financial record, or expose private information, the acceptance contract may require more evidence and a named authority. The second task can be more expensive even with identical token consumption. That is not inefficiency; it is a different product.

The cost account should therefore travel with four declarations: the eligible population, the acceptance standard, the service window, and the consequence of error. Without them, “cost per task” is a number looking for a task.

What the account can change

A complete account does not automatically favor local or hosted models, a larger or smaller model, automation or human work. It makes each route carry the costs it actually creates.

The result may support buying a service because the supplier absorbs capacity risk. It may support controlled hardware because demand is stable and recovery matters. It may support a stronger model because verification falls faster than inference cost rises. It may show that the proposed task should stop because accepted outcomes remain too expensive.

The decision rule I would use is deliberately prosaic: compare routes on cost per accepted outcome at the same acceptance and service requirement, then inspect which cost categories are driving the difference. If the conclusion changes when unresolved work or expert time is restored, the cheaper system was purchased by changing the account.

Tomorrow’s problem is the most common fixed-cost distortion: capacity is paid for before it becomes useful.