How do I forecast LLM costs for next month?

Compute each team's trailing daily run-rate — spend over the last 14 or 28 days divided by the number of days — and multiply by the days in the coming month, then sum the teams. Adjust for known step changes such as launches or model swaps, and exclude flagged anomaly days from the baseline so one runaway loop doesn't inflate the projection.

Why is AI spend so hard to forecast?

Because it is metered by the token and driven by software behavior, not by provisioned capacity. A prompt change, a retrieval step that attaches more documents, or a model swap can shift the run-rate overnight without any infrastructure change. That is why forecasts must be recomputed from a rolling baseline rather than set once at planning time.

What is a run-rate forecast?

A run-rate forecast projects the current pace of spend forward: month-to-date spend plus the trailing daily average times the days remaining in the period. It assumes tomorrow behaves like the recent past, which holds for steady workloads and fails at step changes — which is exactly why it should be paired with anomaly detection and per-team granularity.

How to forecast AI spend (before the invoice surprises you)

A formula-level method for projecting LLM costs: trailing-average baselines, per-team run-rates, anomaly-adjusted trends, and the guardrails that keep the forecast honest.

By Quordo · Published 2026-07-06 · Updated 2026-07-06 · 6 min read

Key takeaways

Forecast AI spend by computing a trailing-average daily run-rate per team (spend over the last N days divided by N) and projecting it over the days remaining in the period: month-to-date spend plus run-rate times days left.
Forecast per team and sum, never from the org total — team-level baselines are tighter, and one team's launch doesn't contaminate everyone's projection.
Exclude flagged anomaly days from the baseline and layer in known step changes (launches, model swaps); back the forecast with budget alerts and hard caps so a miss is caught in days, not at the invoice.

The direct answer

The workable method is a per-team run-rate projection with anomaly hygiene. For each team: take spend over a trailing window (14 or 28 days), divide by the days in the window to get a daily run-rate, and project the period as month-to-date spend plus run-rate times days remaining. Sum the teams for the org number. Exclude flagged anomaly days from the window, layer in known step changes, and recompute daily. That is the whole method — the rest of this article is why each piece is there and where it breaks.

Note what this is not: it is not a claim about what your spend will be, and there is no universal growth percentage to plug in. AI spend is a function of your own workloads' behavior, so the only honest inputs are your own trailing data and your own knowledge of what is about to change.

Why forecast per team instead of from the org total?

The org-level total is the noisiest possible input. It mixes teams that are flat with teams doubling month over month, so the aggregate trend fits nobody and a projection from it inherits the noise. Per-team baselines are tighter — each team's workload mix is more homogeneous — and deviations from them are visible while they are small, which is the same reason anomaly detection operates at that granularity.

Forecasting per team also makes the forecast actionable. An org-level miss is a mystery to investigate; a team-level miss has an owner, a workload, and usually an obvious recent change. And it composes: the org forecast is just the sum, but the sum carries an explanation of itself.

The prerequisite is per-team attribution. If usage is not stamped with the owning team at ingestion, there are no per-team baselines to project from, and the forecast degrades back to the noisy aggregate. Attribution is the foundation; the forecast is a consumer of it.

How do you keep anomalies from poisoning the baseline?

A trailing average treats every day in the window as representative, and some days are not. A runaway agent loop that burned five times the normal rate for two days sits in a 14-day window inflating the run-rate by a large fraction — projecting the accident forward as if it were the trend. The fix is anomaly hygiene: days flagged as anomalous get excluded (or capped to the baseline) before the average is computed.

This is where forecasting and anomaly detection turn out to be the same machinery pointed in different directions. Detection compares today against the trailing baseline to ask 'is this normal?'; forecasting projects that baseline forward to ask 'where does normal land by month end?'. A spend plane that maintains per-team daily baselines gives you both from one dataset.

The opposite adjustment matters too: real step changes belong in the forecast even though they look like anomalies at first. A launched feature, a model swap, or a new team onboarding is a level shift, not a spike. The practical rule: an unexplained deviation is excluded until diagnosed; an explained one resets the baseline from the day it landed.

How do budgets and hard stops fit the forecast?

A forecast without guardrails is a prediction; a forecast with guardrails is a plan. Set each team's monthly budget from its projection plus deliberate headroom, and let threshold alerts do the day-to-day watching: a warning at 80% and an over-alert at the limit convert a forecast miss into a notification that arrives with weeks of the month left, instead of a line item that arrives after it closed.

The forecast also tells you when the alert should have fired. If a team is at 60% of budget on day 10, the run-rate projection says it will finish near 180% — the threshold alert will eventually catch it, but the projection catches it today. Comparing projected end-of-period spend against budget daily is the earliest honest warning you can get.

Hard stops are the last resort, and they are a policy question rather than a math one: for which workloads is an outage cheaper than an overrun? Batch and experimental workloads are usually safe to cap outright; user-facing paths usually are not, and for them the guardrail is fast alerting plus retry caps at the application layer. Decide per workload, in advance, while it is cheap to be wrong.

Where Quordo fits

The method above needs three things from tooling: per-team attributed daily spend, anomaly flags to keep baselines clean, and budgets with early alerts to catch the misses. That is precisely the data Quordo's Spend surface maintains — attribution per team across connected providers, anomaly detection against each day's trailing baseline, and deduplicated threshold alerts written to the audit log and dispatched by webhook — so the forecast becomes a spreadsheet-simple calculation on numbers that are already clean, current, and owned.

For agent-heavy estates there is one more input: per-run cost reconciling into per-mission spend, which lets you forecast at the workflow level — 'this mission pattern costs about this much, and we run it this many times a week' — the shape that agent-driven spend actually grows in.

Frequently asked questions

How do I forecast LLM costs for next month?: Compute each team's trailing daily run-rate — spend over the last 14 or 28 days divided by the number of days — and multiply by the days in the coming month, then sum the teams. Adjust for known step changes such as launches or model swaps, and exclude flagged anomaly days from the baseline so one runaway loop doesn't inflate the projection.
Why is AI spend so hard to forecast?: Because it is metered by the token and driven by software behavior, not by provisioned capacity. A prompt change, a retrieval step that attaches more documents, or a model swap can shift the run-rate overnight without any infrastructure change. That is why forecasts must be recomputed from a rolling baseline rather than set once at planning time.
What is a run-rate forecast?: A run-rate forecast projects the current pace of spend forward: month-to-date spend plus the trailing daily average times the days remaining in the period. It assumes tomorrow behaves like the recent past, which holds for steady workloads and fails at step changes — which is exactly why it should be paired with anomaly detection and per-team granularity.