Putting an AI line in next year's budget

A budget is different from a forecast, and the difference is the reason this goes wrong. A forecast is a best guess you revise. A budget is a number you commit to and get measured against, so being wrong has consequences a forecast never carries. Most annual AI lines are built the same way: take the current month, multiply by twelve, add a round percentage for growth. That method has two blind spots. It treats a growth rate as a single number when it's a range, and it treats today's rates as next year's, which they aren't, because providers publish dated changes ahead of time. Claude Sonnet 5's introductory pricing ends on 2026-09-01 and rises 50%, and that date is public now. A budget built this month that runs through it lands already wrong by an amount you could have looked up. The fix is to budget a range rather than a point, price each month at the rate in effect for that month, and name what you would cut if the top of the range arrives.

• Your annual number is this month times twelve plus a round percentage.
• Nobody checked whether a published rate change lands inside the budget year.
• The budget is a single figure with no range around it.
• Growth was assumed flat because the alternative was arguing about it.
• No agreed action exists for the case where spend runs above plan.

1. Check which of your models have a published rate change dated inside your budget year.
2. Rebuild the annual number month by month at the correct rate for each month.
3. Put a range around it from your slowest and fastest recent growth, not a single figure.
4. Write down what you would cut at the top of the range, before you need to.

Illustrative example

A modelled workload of 10,000M input and 1,000M output tokens a month on Claude Sonnet 5, held flat all year so the rate change is the only thing moving. Sonnet 5's introductory rates are $2.00 and $10.00 per million, and the price book carries a second row effective 2026-09-01 at $3.00 and $15.00. The budget year starts in May, putting four months before the change and eight after. Token volumes and the budget year are modelled, both rates and the date are published.

Usage never moved in this example. The entire $120,000 comes from one published date that anyone could have looked up before the budget was signed, and the run-rate method has no place to put it.

Half of this is public and half of it belongs to you. The rate changes are published, dated, and the same for everybody, so missing one is an avoidable error rather than an act of forecasting. Your usage curve is the other half, and nothing outside your own history predicts it. Culpa forecasts from your own priced calls, deterministically and as a range rather than a single number, against a price book versioned by effective date, so a month after a published change is priced at the rate that applies to it. Every forecast is stored and scored against what actually happened, which is what turns next year's budget into something better than this year's guess. The attribution comes along too, so the annual line splits by product, team or customer, and an overrun has somewhere to be traced to rather than being announced.

• Anthropic Bill Spike: Cache Writes Are Usually the Cause
• Agent Fan Out Cost: Why One Request Becomes Thirty Calls
• Context Creep Cost: When Your Prompt Grows and Nobody Notices
• Failed Call Cost: You Pay for Output You Never Read