# AI budget planning for 2027: a forecasting method

URL: https://infro.io/blog/ai-budget-planning-2027
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-19
Last modified: 2026-10-19
Last reviewed: 2026-10-19 (next review due 2026-11-18)
Topic: Cost and FinOps
Format: Guide

> Plan an AI budget bottom-up: baseline this year's spend by provider, team and product from provider usage APIs and invoices, express it as cost per unit of work, apply each product's growth drivers (agents, coding seats, media) and expected model changes, decide what goes on committed capacity versus pay-as-you-go, add an explicit buffer, and enforce the result with per-project budgets, alerts and monthly reconciliation against the invoice.

Key takeaways:
- Build the budget bottom-up from cost per unit of work, not from last year's total plus a percentage.
- Baseline from the providers' own usage and cost APIs and reconcile to the invoice before you forecast from it.
- Agents, coding tools and media change the number of calls per task; model those drivers per product.
- Put announced deprecations in the plan: a forced migration changes unit cost on a date you already know.
- Keep provider cost and platform charges as separate lines, and enforce the plan with per-project caps, alerts and a monthly reconciliation.

**AI budget planning** for 2027 should start from what you already pay your providers, broken down by unit of work, then apply the drivers that will change each line next year. The method below is bottom-up: baseline this year's spend by provider, team and product; turn it into unit costs; model volume, agent, coding and media growth plus known model changes; decide what goes on committed capacity; add a stated buffer; and enforce the result with budgets and a monthly reconciliation. It works for a platform lead preparing the numbers and a finance partner approving them.

October is the right moment. Most organizations lock next year's budget in the fourth quarter, and AI is now a line large enough to be asked about, but rarely one with a forecast method behind it.

## Why AI budgets go wrong

Three patterns break AI budgets more than any price change:

- **Top-down percentages.** "This year plus 50%" ignores that one product may triple while another is retired.
- **Calls per task change silently.** A feature that moved from one model call to an agent loop can multiply its cost per user without any new users.
- **Estimates never checked against the invoice.** A dashboard that misreads spend by a tenth becomes a budget that misreads it by the same tenth.

The FinOps Foundation's AI working group makes a related point: optimisation and model changes move AI forecasts more than they move most cloud forecasts, so cost has to be tied to units of work and re-forecast as vendor pricing changes[1].

## Step 1: baseline current spend from provider data

Start with what the providers say you spent, not what your own logs estimate.

- **Anthropic** exposes a Usage API grouped by model, workspace, API key and service tier, in 1-minute to 1-day buckets, and a Cost API in USD with daily buckets, grouped by workspace or description. Both need an Admin API credential; workspace keys do not work[2].
- **OpenAI** exposes `/v1/organization/usage/completions`, which can be grouped by model and project, and `/v1/organization/costs`, grouped by line item or project, both called with an admin key[3].
- **Cloud-hosted models** (Azure, Bedrock, Vertex) appear in your cloud bill. Azure provisioned throughput, for example, is tracked in Microsoft Cost Management, including reservation utilisation and amortised cost[4].

Pull at least six months. Then reconcile the total to the invoices for the same months; if your internal attribution disagrees with the provider's cost report, fix that first, because every forecast inherits the gap. The method is in [reconciling LLM spend with provider invoices](https://infro.io/blog/reconcile-llm-spend-provider-invoices).

Break the reconciled total into lines that someone owns: product feature, internal tool, team. Workspaces, projects and API keys are the usual join keys, which is a good reason to issue one key per service. Spend that cannot be attributed becomes its own line called "unattributed", with an owner whose job is to make it smaller.

## Step 2: turn spend into unit costs

A budget line is volume times unit cost. Pick the unit the business already counts:

| Product type | Unit | What drives the unit cost |
| --- | --- | --- |
| Support assistant | Resolved conversation | Turns per conversation, retrieval size, model |
| Coding agent | Active developer per month | Tasks per developer, steps per task, context size |
| Document pipeline | Page or document processed | Pages per document, batch versus synchronous |
| Agent workflow | Completed task | Steps per task, retries, tools called |
| Media feature | Image, second of video, minute of audio | Resolution, duration, model |

Count failed and retried work in the unit cost; you pay for it. For agents, cost per completed task is the only stable unit, and capping steps gives it an upper bound — see [cost per successful task](https://infro.io/blog/cost-per-successful-task) and [bounding agent loops](https://infro.io/blog/bound-ai-agent-loops).

## Step 3: model the growth drivers per line

For each line, write down the volume driver and the unit-cost driver separately, with the assumption behind each:

- **Volume.** Users, seats, documents, conversations. Use the product plan, not a trend line.
- **Agents.** A feature moving from single calls to an agent changes calls per task. Model it as a unit-cost change on the launch date.
- **Coding agents.** Budget per developer seat with an assumed tasks-per-week figure, and a separate line for heavy users. Per-developer spend is uneven.
- **Media.** Image, video and audio are priced per output, not per token. A launch that adds video changes the shape of the line, not just its size.
- **Caching and batch.** Moving stable prompt prefixes into a cache, or offline work to a batch tier, lowers unit cost; count it only when the work is scheduled.

## Step 4: price movement and model deprecations

Prices and models change inside a budget year, and some of the changes are already announced. OpenAI's deprecations page lists shutdowns scheduled across the first months of 2027, among them GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini on 14 January 2027 with `gpt-6-luna` as the recommended replacement[5]. OpenAI commits to at least six months' notice for generally available models, three months for specialised variants, and much shorter for previews[5].

For every model in your baseline, check its vendor's deprecation page and add a dated row to the plan: the migration date, the replacement, the replacement's list rate, and an evaluation cost for the migration itself. A replacement with a different rate or different token usage changes that line's unit cost from that date. The [model deprecation migration playbook](https://infro.io/blog/model-deprecation-migration-playbook) covers the evaluation.

Do not forecast general price declines you cannot point to. If you expect a model with a lower rate to replace one with a higher rate, write it as a planned migration with a date and an owner, so the saving is a commitment rather than a hope.

## Step 5: committed capacity, on-demand and negotiated rates

Decide which lines are steady enough to commit:

- **Provisioned capacity.** Azure, for example, bills provisioned deployments per PTU per hour, with one-month or one-year Azure Reservations for a discounted rate; Microsoft notes reservations do not guarantee capacity, so create the deployment first[4]. It suits predictable, latency-sensitive production traffic. Standard pay-per-token suits variable or early-stage traffic[4].
- **Committed-spend agreements.** If you negotiate a commitment directly with a provider, put the committed amount in the plan as a floor, track draw-down monthly, and forecast to the end of the term.
- **Negotiated rates.** If your contract carries rates other than list, forecast with the contract rate and record the effective date. List rate versus negotiated rate drift is covered in [negotiated rates and list-price drift](https://infro.io/blog/negotiated-rates-list-price-drift).

## Step 6: buffers and separate lines

Add a buffer as an explicit line, sized from this year's variance between forecast and actual, not as padding hidden in every row. Keep these as separate lines too:

- **Provider cost**, what your AI providers bill you, by product and team.
- **Platform and tooling charges**, gateway, observability or evaluation subscriptions. They are priced differently and should never be summed into a per-token figure.
- **One-off migration and evaluation work** for the deprecations in Step 4.
- **Unpriced or unattributed** usage, with a target to shrink it.

## A worked example

> **Example: A 2027 forecast for one organization (illustrative figures)**
> Baseline: average month of Q3 2026, reconciled to provider invoices. All figures invented for illustration.
> 
> | Line | Q3 2026 monthly | Unit cost now | Driver assumption for 2027 | Dec 2027 monthly |
> | --- | --- | --- | --- | --- |
> | Support assistant | $8,400 | $0.021 per resolved conversation (400,000) | Volume +40%; migration to a newer model lowers unit cost 15% in March | $9,996 |
> | Coding agents | $37,200 | $310 per developer (120) | 200 developers; tasks per developer +30% | $80,600 |
> | Document extraction | $4,000 | $0.0016 per page (2.5M) | Volume ×2; moved to batch tier, unit cost −30% | $5,600 |
> | Media generation | $6,000 | Experiments, no unit yet | Video feature launches in Q2 | $15,000 |
> | Total provider cost | $55,600 |  |  | $111,196 |
> 
> With a roughly linear ramp from January to December, the 2027 provider-cost base is about 12 × ($55,600 + $111,196) ÷ 2 ≈ $1.0M. A 15% buffer, sized from this year's forecast error, adds about $150,000. Platform and tooling subscriptions and a one-off migration evaluation are listed separately, never folded into the per-unit rows.
> 
> The coding line is two-thirds of the December run rate. That is where the guardrails, the reporting and the negotiation effort should go first.

## Step 7: guardrails that keep the year inside the plan

A budget nobody enforces is a forecast. Turn each line into controls:

- **Monthly caps per project or team**, matching the budget lines, with alerts at thresholds such as 50%, 80% and 100% of the month.
- **Per-key caps** for agents and batch jobs, so one runaway loop cannot spend a team's month. See [LLM spend controls and budgets](https://infro.io/blog/llm-spend-controls-budgets).
- **Forecast alerts**: a warning when the month is projected to exceed its line, not only when it has.
- **Showback, then chargeback.** Send each owner their line weekly; move to chargeback once the attribution is trusted. The [showback and chargeback guide](https://infro.io/blog/ai-spend-showback-chargeback) covers both.
- **A monthly report for leadership** with budget, actual, projection and the decisions needed. The format is in [the AI spend report for leadership](https://infro.io/blog/ai-spend-report-for-leadership).
- **Monthly reconciliation** of your estimates against each provider's reported cost.

The broader practice, from tagging to unit economics, is in the [LLM FinOps guide](https://infro.io/blog/llm-finops-guide).

## Running the plan with INFRO

INFRO sits in front of the provider accounts you already hold, and its figures are estimated provider cost — what your providers will bill you — kept apart from INFRO's own subscription. Budgets are hard caps per organization, project, member and key, with alerts at your own thresholds, so the lines in the plan become enforced limits. Spend findings include a budget forecast to be exceeded, cost estimates drifting from the provider's own figures and unpriced traffic, routed to email, Slack, Teams, PagerDuty or webhooks depending on plan. The Summary shows this budget cycle's spend against budget with its projection, and is emailed weekly with a monthly report on the 2nd.

For the baseline and the contract terms: negotiated rates can be entered per model so estimates use your contract before list rates (from the Team plan); reconciliation compares estimated spend daily with OpenAI's and Anthropic's own cost APIs; and committed-spend agreements can be tracked against reported cost with a forecast to the end of the term (both on the Business plan). Usage exports as CSV or a FOCUS dataset for your FinOps platform.

## Questions

### How much buffer should an AI budget include?

There is no standard figure. Size it from your own variance: look at how far each month of this year landed from the run rate before it, and how much of that came from new launches versus usage drift. A product still finding its usage pattern needs a wider band than a steady internal tool. State the buffer as its own line so it is spent deliberately.

### Should AI spend be forecast monthly or annually?

Set the annual budget once, but re-forecast monthly. Model prices, model versions and usage patterns move within a year, and the FinOps Foundation's AI working group recommends revisiting forecasts as vendor pricing changes.

### Who should own the AI budget, platform or finance?

Usually both: finance owns the total and the approval, product or platform teams own their lines, and the platform team owns the guardrails that enforce them. What matters is that every line has one named owner who sees its spend weekly.

### How do you forecast AI agent costs?

Measure cost per completed task, not per request, because an agent makes many calls per task and the count varies. Multiply by expected task volume, and cap steps per task so the unit cost has an upper bound you can plan around.

## Sources

1. Effect of Optimization on AI Forecasting — FinOps Foundation. https://www.finops.org/wg/effect-of-optimization-on-ai-forecasting/ (accessed 2026-10-19)
2. Usage and Cost API — Anthropic. https://platform.claude.com/docs/en/manage-claude/usage-cost-api (accessed 2026-10-19)
3. How to use the Usage API and Cost API to monitor your OpenAI usage — OpenAI. https://developers.openai.com/cookbook/examples/completions_usage_api (accessed 2026-10-19)
4. Provisioned throughput for Foundry Models — Microsoft Learn. https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/provisioned-throughput (accessed 2026-10-19)
5. Deprecations — OpenAI. https://developers.openai.com/api/docs/deprecations (accessed 2026-10-19)