Forecasting Next Quarter's AI Spend as a Range

The standard AI forecast is last quarter multiplied by a growth factor somebody felt comfortable defending. It is wrong roughly every time, usually low, and the failure is not in the arithmetic. It is that a single trended series cannot represent a cost whose drivers move independently and in steps.

A forecast is useful if it tells you which assumption to revisit when the number comes in wrong. That means decomposing spend into drivers, giving each a range, and reporting the result as a range too.

Why extrapolating tokens does not work

Token consumption is not a smooth series that happens to be noisy. It is a step function produced by discrete events, and trend-fitting a step function reliably underestimates the next step.

Consider what actually moved your last three months. A team adopted an agentic workflow in week six, which multiplied per-developer consumption rather than adding to it. A prompt change in week nine raised average input by half. Someone enabled a reasoning-heavy configuration for a subset of tasks in week eleven. A linear fit through the resulting curve produces a slope that describes none of those events and predicts a fourth one that has no reason to resemble the first three.

There is also a definitional problem. Tokens are only proportional to cost when the price per token is constant, and it is not: input, output and cached input are priced differently, the mix between them shifts as workloads change, and the model mix shifts underneath all of it. Forecast the cost, driven by the things that move it. Do not forecast the token count and convert.

The drivers that actually move the bill

Four things account for nearly all of it, and each behaves differently enough to need its own treatment.

Headcount. The most predictable driver and usually the smallest surprise, because hiring plans exist. Multiply by an observed per-developer figure rather than a target one, and use the median rather than the mean — a couple of heavy users will otherwise inflate the assumption for everybody. AI cost per developer per month covers how to compute a figure that holds up.

Agent adoption. The largest and least linear driver. Moving a developer from chat-style assistance to an agentic loop typically changes their consumption by a multiple, not a percentage, because an agent resends accumulated context on every turn. Model this as a share of the team that has adopted, times a separate per-user figure for that mode, not as growth on the existing average. Why agent costs are unpredictable covers the mechanism.

Context growth. Average input per request drifts upward almost everywhere: more retrieved chunks, longer system prompts, larger files attached, more tool results kept in the transcript. It is slow, it never triggers an alert, and over two quarters it can be worth as much as a headcount change. Measure your own trailing rate rather than assuming a number. The hidden cost of context bloat covers where it comes from.

Model tier changes. Discrete and large. A default route moving to a more capable tier, a fallback firing more often, a deprecation forcing a migration. These do not trend at all — they happen on a date — so they belong in the forecast as scenarios with probabilities, not as part of the slope.

Build the range from driver ranges

Give each driver a low, expected and high value, then combine. The point is not statistical rigour; it is that the width of the output tells you how much confidence to place in it.

Do not simply add all the lows to get the low case and all the highs to get the high case, because that produces an interval so wide it is useless and implies the drivers are perfectly correlated. Some genuinely are — agent adoption and context growth tend to move together, since agents accumulate context — and those should be modelled as moving together. Headcount is largely independent of both.

A practical compromise: build the expected case from expected values, then produce a high case by moving only the two drivers with the widest uncertainty to their high values, and a low case the same way. Three numbers, an explicit list of which assumptions produced each, and no false precision. If the high case is more than about twice the low case, the forecast is not yet informative and the fix is to narrow the widest driver by measuring it rather than by guessing harder.

Handling a price change mid-forecast

Model prices move, occasionally by a lot, and a forecast built on today's rate card quietly becomes a forecast of something else.

Keep price as an explicit multiplier per model rather than folding it into a blended cost per unit of work. Then a rate change is a one-line edit and you can restate the forecast in an hour instead of rebuilding it. This is also what lets you answer the question that follows any price move: what would our last quarter have cost at the new rates?

Treat announced changes and speculative ones differently. An announced change with a date goes into the expected case, prorated across the affected portion of the quarter. A possible one goes into the high or low scenario with the assumption written down. Deprecations deserve particular care because they force a migration on the provider's schedule rather than yours, and the replacement model is frequently priced differently and consumes a different number of output tokens for the same task. Model deprecation and migration covers planning for that.

Where a price change would meaningfully alter your decisions, the alternative is to remove the variable: flat-rate access converts the whole term into a fixed per-seat number, which forecasts trivially at the cost of some efficiency at low usage. It is the reason ProjectCOZY prices that way, and it is the wrong trade if your usage is genuinely small or highly variable.

Forecast per workload, then sum

A single company-wide series mixes workloads whose drivers have nothing in common, so no single growth assumption fits any of them.

An interactive assistant scales with headcount and adoption. A CI review bot scales with pull request volume, which scales with headcount but with a lag and a different multiplier. A batch pipeline scales with document volume, which may be entirely driven by customer growth. A research or evaluation workload is lumpy and project-driven, and is best forecast as a fixed allowance rather than a trend.

Forecasting each separately takes longer the first time and is faster every subsequent quarter, because you are updating four small models rather than rebuilding one large intuition. It also makes the variance attributable: when the quarter comes in high, you can say which workload did it.

Check the forecast against the last one

The habit that improves forecasts is not better modelling, it is reviewing the previous one against actuals and recording why it was wrong.

Do it at the driver level. Was the miss in headcount, in adoption rate, in context growth, in price, or in a workload that did not exist when the forecast was made? The last category is more common than anyone expects and is the honest reason to keep an explicit unallocated line — call it new initiatives, size it from history, and stop pretending it is zero.

After two or three cycles the systematic bias becomes obvious. Most teams find they consistently underestimate adoption and consistently overestimate the effect of the optimisations they planned but did not finish. Adjust for both. Forecasting AI spend without guessing covers the underlying unit-economics model in more detail.

What to hand to finance

Three numbers with the assumptions beside them, one line per workload, an explicit unallocated allowance, and a named owner for each driver who will notice if it moves. Plus a statement of what would make you revise: a price change, an adoption milestone, a headcount change beyond the plan.

That last part is what turns a forecast from a prediction into a control. A number that nobody revisits until the quarter closes was never a forecast; it was a hope with a spreadsheet around it.