AI cost forecasting: how usage grows and how to cap it
AI usage grows in steps, not lines. How to forecast a year from a month of logs, the growth patterns to expect, and the caps that make it safe.
The short answer
AI cost is the number of calls, times the size of each call, times the price per unit for the model used. Forecasting means projecting each of the three separately, because they move for different reasons. Calls grow with adoption and new features, in steps rather than lines: a team starts using it, a feature launches, an integration begins sending every record. Size grows when more context, longer history or whole documents are sent. Price falls, repeatedly, as providers compete. A month of real logs gives the baseline for all three; the planned steps give the growth; caps at the provider, per feature and per user make the forecast safe against the steps nobody planned.
The three factors and how they move
| Factor | What moves it | Direction | How to forecast |
|---|---|---|---|
| Calls | Adoption, new features, integrations, bots, loops | Up, in steps | Planned launches and rollouts; headcount as the ceiling for internal tools |
| Size per call | Context sent, conversation history, document size, output length | Up, unless disciplined | Log input and output sizes; model the effect of each feature change |
| Price per unit | Provider pricing, model choice per step | Down over time; up if you switch tiers | Current price list; assume declines but do not budget on them |
Forecasting a year
- Take a month of logs: calls, sizes, model per step, cost. Compute cost per case.
- List the planned steps: teams to onboard, features to launch, document sets to add, integrations to connect, with months.
- Estimate calls per step from the pilot’s per-user or per-record numbers.
- Hold size per call constant unless a feature changes it; if one does, estimate the new size.
- Use current prices; note expected declines as upside, not budget.
- Produce low, expected and high scenarios; budget expected, cap at high.
- Revisit quarterly against actuals and price changes.
The caps
At the provider account: a monthly and daily ceiling above the high scenario, so nothing can exceed it without a person raising it. Per feature: a budget and a rate limit, so one feature cannot consume the others’ allowance. Per user or per client: a fair-use limit, so one heavy user or one runaway script is contained. Alerts on cost per case and on daily spend versus forecast, routed to the internal owner. The caps are not savings on normal days; they are the reason the forecast can be trusted.
What this means for you
Forecast calls, size and price separately from a month of real logs and the steps you plan. Budget the expected scenario, cap at the high one at three levels, and alert on cost per case. Revisit quarterly, because prices fall and usage climbs in steps. Done this way, AI usage is a forecastable line, and the surprises are alerts rather than invoices.
Frequently asked questions
Our usage doubled last month. Is that normal?
It is normal if something changed: a new team started using it, a feature launched, a larger document set was indexed. Look at cost per case first. If it is flat and calls doubled, adoption grew, which is what you wanted. If cost per case doubled, inputs got larger or a model changed, and that is a design question, not a growth one.
How do we budget when we do not know how many people will use it?
Forecast in scenarios from the pilot's numbers: cost per case from the pilot, times cases per user per month, times users in a low, expected and high adoption scenario. Budget the expected, cap at the high, and review monthly. The pilot gives you the per-case number; adoption is the only unknown, and it is bounded by headcount.
Do AI costs go down over time?
Per unit, yes, repeatedly and steeply so far: the same capability costs a fraction of what it did two years ago. Total cost can still rise because usage grows faster than prices fall. Forecast usage growth on your side and price decline on the provider's, and revisit every quarter; the arithmetic changes often enough to matter.