Quick answerForecast as a range tied to a volume driver, not a single number tied to a calendar period. Pick the metric that actually drives your token or call volume, conversations handled, messages per conversation, or a similar usage proxy, and build the cost forecast as cost-per-unit times a volume range, updated monthly against actuals rather than set once a year and left alone. Keep a separate line for provider price changes themselves, since a per-token rate cut or increase is a different kind of variance than your own usage growing, and conflating the two makes it impossible to tell whether a forecast miss came from more customers or from a vendor repricing.
Why an annual planning cycle alone cannot solve this
Our post on how to run an annual budget and roadmap planning cycle for your AI agent program covers the yearly ritual: reviewing last year's numbers, the vendor landscape, and the capability backlog, then producing a funded roadmap. That process answers what to invest in over the year. It does not answer how to predict a monthly operating cost that moves with usage and with provider pricing changes that can land at any point in the year, which needs its own, more frequent forecasting motion layered underneath the annual cycle.
Pick a volume driver you can actually measure before pricing gets involved
The forecasting method only works if you have a clean usage metric that predicts token or call volume reasonably well, and that metric needs to be something your product team already tracks for other reasons, like conversations handled or active accounts, rather than something invented specifically for this forecast. Building the cost model on a volume driver you are already forecasting for other purposes means your cost forecast inherits whatever forecasting discipline already exists elsewhere in the business instead of starting from scratch.
Separate usage growth from provider repricing in the model
Grounding the forecast in what it actually costs to run at your current scale, covered in what it actually costs to run an AI agent at scale, gives you the current cost-per-unit baseline. From there, model two variances separately: your own volume moving up or down, and the provider's per-token price moving independently of anything you did. A forecast miss that blends both causes together makes it much harder to react correctly, since a volume-driven miss calls for a different response than a pricing-driven one.
Hold a contingency line for the tail risk this creates
Even a good forecasting method leaves a real tail risk: a usage spike and a price increase landing in the same month, or a spike large enough to blow past any range you modeled. The reserve-sizing discipline covered in how much to hold in reserve for AI agent error costs applies just as well here; keep a contingency line sized against your worst realistic monthly variance, not against the average case the forecast is built around.
FAQ
How often should the forecast be refreshed?
Monthly at minimum, reconciled against actual spend, with a lighter quarterly check on whether the underlying volume driver still predicts usage as well as it did when you picked it.
Should sales or product commit to a fixed monthly AI cost number internally?
No, commit to the range and the volume assumption behind it, since a fixed internal number just moves the same forecasting problem one level down without actually solving it.