Plenty of AI budgets for next year are already drafted, built from trailing spend plus a growth factor, which is how cloud budgets have been built for a decade. In cloud, that method works.
Applied to AI spend, it produces numbers that miss by multiples and occasionally by orders of magnitude. A forecast gets approved, and then a team ships something that consumes at a rate the model never accounted for, with the variance surfacing around the time the invoice does.
These misses follow a pattern, because AI spend breaks a handful of specific assumptions buried inside any trend line. A forecast rebuilt on different inputs holds up considerably better.
The reasonable version of the objection
Most forecasting processes were built for cloud spend, where they work well. Cloud spend carries over from one period into the next, so last quarter predicts next quarter, the underlying resources persist, and growth stays roughly continuous. Big step changes come from deliberate decisions that someone can flag in advance. A FinOps team applying trailing twelve months plus a growth factor to cloud is doing sound work.
Applied to AI spend, that same method assumes a history that constrains the future, and AI spend carries no such constraint.
It's common for a team to spend double digits one month and five figures three months later, with nothing resembling a ramp in between. A trend line fitted to the early month forecasts something near zero, and one fitted to the later month carries a growth rate that flattens almost immediately. Neither line describes spend that moves in steps.
Why the trend line misses
Three mechanics do most of the damage, and they compound on each other.
Agents consume without a stopping condition. This is the largest single factor, and most models don't represent it at all. An agent running open loop has nothing telling it what it's consuming against the goal it's chasing, so a small question can return an exhaustive answer at a cost to match. Consumption scales with how hard the task looks to the agent, and the same task can look harder next month after a small prompt change.
A forecast built on requests per month assumes every request costs about the same, and agentic workloads break that assumption.
Adoption arrives in steps. New capabilities ship and a workload appears at full volume, without the ramp a slope assumes. In a business running most of its operations on AI models, one workload arriving at scale can land an order of magnitude above what the planning number assumed. A model tuned to predict percentage growth won't produce a jump like that.
Cost per unit of work is unknown at the moment of the decision. Teams ship features without knowing what the feature costs to run. Whoever builds a feature often has a rough sense of what one call consumes, and that number travels as an informal warning to the next person who uses it. The unit economics of a new product feature end up living in chat, and the forecast finance maintains doesn't contain them.
The inputs a working forecast needs
A forecast that holds up needs three inputs, and most teams already have the data for the first two.
Cost per unit of work, measured from current spend. The unit should be something the business already produces, like a resolved ticket or a processed image, measured at what one costs today. That replaces the per-token pricing assumption behind most of the damage, since token price stays fairly stable and tokens per unit of work moves around.
A committed volume curve from the teams shipping the work. The useful request is for the specific things going live next quarter and the volume each one carries, instead of a growth rate. A single workload can carry enough volume to multiply current spend several hundred times over while its per-unit cost stays entirely reasonable. That volume is usually known somewhere inside the company long before it reaches a forecast, and the late arrival is what produces the miss.
A ceiling that can be enforced. A forecast without an enforcement mechanism stays a prediction, since the number holds only for as long as every team behaves. This is the input teams skip most often, and it's what gives the other two any weight.
A method to run this quarter
This takes an afternoon and a spreadsheet. The first step is last month's total divided by units of work delivered, using whatever unit the business already counts, which gives current cost per unit. The second is a volume forecast from every team shipping AI-backed work, stated in units instead of dollars, multiplied through. The third triples the largest single line, since that line is where a step change will land and agentic workloads consume more per unit as they get more autonomous.
That total set against the current budget shows the exposure, and it's a more honest number than a trend line produces.
A hard threshold then belongs at the level where the exposure becomes unmanageable, with the alert routed to whoever will have to explain it. Setting that line in advance is what makes the alert worth acting on when it fires.
Where Revenium fits
The measurement side of this is where we can help immediately.
Export Cost & Usage Data (FOCUS) gets your history into a form you can model against in a standard schema. Analyze ROI & Unit Economics is where cost per unit of work stops being an estimate. Predict & Surface Anomalies catches the step change closer to when it happens rather than at month end. Set Budgets & Alerts turns the threshold into something that fires. Build Custom Dashboards & Charts is how the quarterly exercise becomes a standing view.
The method above fits inside a planning cycle and produces a number that can be defended in the room.
