Token Run-Cost: The Line Missing From Most AI Business Cases
The line missing from most AI business cases is token run-cost — the per-call inference spend that scales directly with usage volume, not the one-time development cost or the ongoing model-monitoring cost most finance reviews already ask about. A business case that rolls token run-cost into a generic "operational cost" catch-all, or omits it because the pilot's usage was too small to notice, understates the investment's true ongoing cost the moment usage scales.
Why This Line Gets Missed
The other four categories a complete AI cost model has to cover — model development and MLOps, change management, ongoing maintenance and monitoring, and opportunity cost — are covered in Why Most AI Business Cases Collapse Under Finance Scrutiny. Model development and MLOps is a cost to build the system. Change management is a cost to get the organization to adopt it. Ongoing maintenance and monitoring is a cost to keep the model healthy — tracking drift, running retraining cycles. Token run-cost is none of these. It is the cost of the system actually being used, call by call, and it is the only one of the five lines that is directly proportional to adoption succeeding. The more successful the rollout, the larger this line gets — which is exactly why a business case that treats it as a rounding error gets a painful surprise once usage actually scales.
How to Size It Without a Production Track Record Yet
Build the figure from projected call volume multiplied by per-call token cost at the model's current pricing tier, projected across the full adoption curve of the investment horizon — not a flat run-rate assumed to hold from month one. Treat the per-call token cost itself as a line that can shift, not a constant: more context retrieved per call, longer conversation history carried forward, or a change in which model serves the workload can each move it independently of volume.
A Hypothetical Illustration
Picture a business case built for an AI-assisted document review system, with model development, change management, and ongoing monitoring all carefully estimated as the existing post describes. The case gets approved, the system goes live, and adoption succeeds exactly as planned — which is also the moment token run-cost starts showing up as a line item nobody sized in advance, because the original case never separated it from the general "operational cost" figure it was folded into. The business case was not wrong about whether the investment would work. It was incomplete about what success would actually cost once it started working.
Where It Belongs in the NPV
Token run-cost is operational expenditure that continues for the life of the system, and it has to be discounted across every year of the investment horizon the same way benefits are — not presented as a single number bolted onto the capital cost. Treating a recurring, usage-scaling cash outflow as a one-time figure distorts both the NPV and the payback period, in the direction that makes the case look stronger than it actually is until the first full year of production usage lands.
Why This Line Deserves Its Own Scrutiny
The other four cost categories in a complete AI business case are, in a real sense, bounded: a development budget has a ceiling once the system ships, a change-management programme has a defined duration, and even ongoing monitoring infrastructure has a relatively flat run-rate once it's built. Token run-cost has no such ceiling by design — it is meant to keep rising as adoption succeeds, because that is what a successful rollout looks like from a usage-volume perspective. That is precisely why it belongs in the business case as its own explicit, usage-linked line rather than a rounded-up addition to a budget built around the other four, bounded categories.
Naming It Does Not Mean Overstating It
Adding token run-cost as its own line is not an argument for padding the business case with a worst-case number to look thorough. It is an argument for sizing it honestly, at the adoption curve the case actually assumes, and revisiting it at the same cadence the case revisits its benefit assumptions. A business case that names this line explicitly, even at a modest early estimate, reads as more complete to a finance reviewer than one that omits it — because the omission itself is what erodes trust once the real bill arrives.
The AI Investment ROI Model provides a 10-tab Excel workbook with NPV, IRR, payback period and benefit-cost ratio calculated across Conservative, Base and Stretch scenarios, with a dedicated cost model tab and sensitivity analysis showing which cost or benefit assumption moves the result most.
→ Available at www.viksya.com