AI spend is showing up in budgets now, and it does not behave like the software line items finance already knows. There is no seat count to multiply. The vendor meters usage in tokens and bills by consumption, so the cost of a team depends entirely on what they are asking the AI to do. Two workloads at the same headcount can differ by more than two orders of magnitude.

The model below is how I handle that. It is a driver-based model, the same discipline you would use for revenue or headcount planning, pointed at API spend. Volume-driven workloads, like a support chatbot or a nightly document job, plan off request counts. People-driven workloads, like a research agent or an internal assistant, plan off seats, adoption, and requests per user per day. Every workload builds up to tokens per request, tokens roll to dollars at the model’s rates, and the cost report at the bottom is the number you take to the forecast.

This version is live. The yellow cells are inputs, the same convention as an EPM webform, and the model recomputes as you change them. Reset puts the seed case back, so you cannot break anything.

A few things worth trying. Raise adoption on the RAG assistant and watch how a people-driven workload scales differently than a volume one. Move the research agent’s cache hit rate and see why prompt caching is the single biggest lever in the model. Then look at the actuals section and the latest estimate, because a model you never reconcile to the bill is a guess, not a forecast.

Here is the part I would not gloss over. The token math is not the hard part. The hard part is deciding what drives each workload, and that is a judgment about how your business uses AI, not a formula. The model gives you a place to write that judgment down where the numbers can argue with it.

Prices are list rates verified July 2026 and exclude negotiated discounts.