Finance asks what AI will cost next quarter. The naive answer extrapolates last quarter's total, which is wrong in both directions: it misses that per-task cost is falling as models get cheaper, and it misses that task volume and complexity are rising faster.
A forecast that holds up decomposes the total into drivers that move independently, and states its assumptions explicitly enough that being wrong is informative.
The Decomposition
Total spend is roughly:
Task volume × cost per task, summed across task types.
Each factor has its own drivers.
Task volume is driven by user or transaction growth, feature adoption, and automation rate — the share of eligible work being handled by agents rather than humans. Automation rate is usually the fastest-moving factor and the one most under your control, which makes it the most important input and the one most often left implicit.
Cost per task is driven by tokens per task, the price of the model serving it, cache hit rate, retry rate, and trajectory length. Provider prices trend down over time for a given capability level; your token consumption per task tends to trend up as agents take on more complex work.
Forecasting the components separately matters because they move in opposite directions. A forecast that shows flat spend may be hiding volume doubling while per-task cost halves — and if either assumption is wrong, the total is wrong by a large factor.
The Non-Linearities
Several effects break naive linear projection.
Trajectory length. Because most agent loops resend accumulated context on every step, token consumption grows roughly quadratically with step count. A task that goes from four steps to six is not 50% more expensive — it can be more than double. Small increases in task complexity produce large cost increases, and this is the most common reason forecasts under-predict.
Context growth. Longer conversations, more retrieved chunks, larger tool outputs. Each step's input includes everything before it, so context growth compounds with trajectory length.
Fan-out. Multi-agent orchestration multiplies. One task dispatching to five sub-agents that each run their own loop is not five times a single agent's cost — it depends on each sub-agent's trajectory. Forecasts built on single-agent measurements will be badly wrong for orchestrated workloads.
Caching, in the other direction. Cache hit rate improves per-token cost meaningfully and depends on traffic density, so a growing workload gets cheaper per token as prefixes stay warm. This partially offsets the above, and it is why a forecast should model cached and uncached tokens separately. See prompt caching to cut inference cost.
Capacity Constraints Are Not Just Budget
Budget is one ceiling. Others often bind first.
Provider rate limits. Requests and tokens per minute, per model, per account. A workload that fits the budget can still fail because it exceeds throughput limits during peaks. Plan against your peak-minute rate, not your monthly average — a workload with a 10:1 peak-to-average ratio needs ten times the limit that average volume implies. Negotiating limit increases takes time, so this needs lead time in the plan.
Self-hosted GPU capacity. If you run models yourself, capacity is a step function measured in GPU-hours and provisioned in advance. Under-provision and you queue; over-provision and you pay for idle silicon. Utilization forecasting matters more here than cost forecasting.
Concurrency. Long-running agent tasks hold resources — connections, memory, worker slots. Peak concurrent tasks is a capacity number distinct from throughput.
Downstream systems. Agents calling internal APIs and databases at machine speed can exceed those systems' capacity, and that failure looks like an agent problem while being a capacity-planning miss. Include downstream load in the plan.
Human review capacity. Where actions require approval, the reviewers are a capacity constraint. An automation rate increase that triples approval volume without adding reviewers produces a queue, and then approval fatigue. See human-in-the-loop approvals for agents.
Building the Forecast
Start from measured per-task cost by task type. Not an average across everything — task types differ by orders of magnitude, and the mix shifting is a major driver. This requires attribution at task granularity. See spend attribution and showback.
Model volume from business drivers. Tie agent task volume to something the business already forecasts — transactions, tickets, users, documents. Then agent spend inherits the business forecast rather than being an independent guess, which also makes it defensible in a planning conversation.
Make the automation rate explicit. "We currently automate 30% of tier-one tickets and plan to reach 60%." This is usually the largest single lever and it is a decision rather than a prediction, so it belongs in the forecast as a stated plan.
Forecast a range. Low, expected, and high, each with the assumptions that produce it. A point estimate invites false confidence and gets treated as a commitment.
Include the non-inference costs. Vector store operations, sandbox compute, paid tool APIs, egress, observability storage. For retrieval-heavy or execution-heavy agents these can rival inference.
Re-forecast monthly and track the error. Recording forecast versus actual is what turns forecasting into a skill rather than a ritual. Persistent bias in one direction tells you which assumption is wrong.
Reserved Capacity and Commitments
Providers offer discounts for committed throughput or volume. The trade is straightforward and the sizing decision is where teams lose money.
Commit to your confident floor, not your expected volume. If your p10 monthly volume is well below your expected volume, commit near the p10 and serve the remainder on demand. Over-committing means paying for capacity you do not use, which erases the discount and then some.
Self-hosted capacity follows the same logic at coarser granularity: size the persistent fleet to the steady baseline and burst to a commercial provider for peaks. That hybrid is usually cheaper than provisioning for peak, and it requires routing that can shift traffic between substrates. See model routing and cost-quality tradeoffs.
Connecting Forecast to Control
A forecast is planning; ceilings are enforcement. They should be connected but not identical.
Set hard caps above the forecast high case with headroom, so normal variance does not block legitimate work and a genuine runaway still hits a wall. Set alert thresholds near the forecast expected case, so drift is visible early. And project month-end spend from run rate continuously — a forecast breach detected on day ten leaves time to act, while one detected on day twenty-eight does not.
The forecast also tells you which caps matter. If one agent is projected to account for most of the growth, that is where the per-agent ceiling needs attention. See budget policies and hard spend caps and anomaly detection on agent spend.
Common questions
How far out can I forecast usefully?
A quarter with reasonable confidence, a year with wide bands. The dominant uncertainties beyond a quarter are your own automation decisions and provider pricing, and both move a lot. Annual planning is better expressed as a range with named decision points — "if we reach 60% automation, spend lands here; if we stay at 30%, here" — than as a single number.
Should I forecast in tokens or in currency?
Both, separately. Tokens are the physical quantity your architecture determines; currency depends on prices you do not control. Forecasting tokens and applying a price scenario separately lets you distinguish "we are consuming more" from "prices changed," which are different problems with different owners.
How do I forecast a workload that does not exist yet?
Prototype and measure rather than estimate. Build the agent, run it on a representative sample, and measure cost per task directly — a day of work replaces a month of arguing about assumptions. Then apply your volume forecast. For the volume side, use whatever process the equivalent human work already follows.
What about the cost of evaluation and testing?
Include it; it is not trivial. A comprehensive eval suite run on every change plus a nightly full suite plus adversarial testing consumes real inference volume — for some teams a noticeable fraction of production spend. It is worth it, and it should be a visible line in the forecast rather than a surprise. See agent evaluations: catching quality regressions.
How Praesidia approaches forecasting inputs
Praesidia meters every governed call with per-agent, per-connection, per-principal, per-tenant, and per-task attribution, separating cached from uncached input tokens and recording the model version and applied rate — which gives forecasting measured cost per task by task type rather than an aggregate to extrapolate. Because task identifiers propagate across sub-agent dispatch, orchestrated workloads roll up to the originating task, so fan-out is visible in the data rather than an unmodeled surprise.
Ceilings enforce at agent, connection, team, and organization level and can be set from the forecast, while spend time series and run-rate views support early detection of a breach. See FinOps for AI agents and the Praesidia documentation.