Why AI API prices keep changing

Most infrastructure pricing is sticky — compute, storage and bandwidth rates move slowly and rarely drop without a public announcement well in advance. LLM API pricing doesn't behave that way. New model generations ship every few months, older tiers get discounted or deprecated, and providers frequently launch a model at introductory pricing that reverts to a standard rate on a fixed future date. If you built a cost model six months ago and haven't checked it since, there's a good chance at least one number in it is wrong.

The usual drivers

• New model launches — a new generation typically ships alongside a fresh price, and the outgoing generation is marked legacy or deprecated rather than staying at its old price indefinitely.
• Introductory pricing that expires on a stated date — some providers launch a flagship at a discounted rate for a limited window, then revert to standard pricing once it ends.
• Competitive repricing — a provider cutting a tier's price in response to a competitor's launch, sometimes announced quietly in documentation rather than as a headline change.
• Infrastructure cost shifts — as inference gets cheaper on the provider's side, older or smaller models sometimes get repriced downward well after launch.

A real example: scheduled reversion

It's common enough for a provider to publish, on its own official pricing page, a specific end date for introductory pricing on a given model — meaning the price you're budgeting against today is already scheduled to change, not just liable to change. Claude Sonnet 5 is a live example of exactly this pattern in the current dataset: check its model page for the current rate and the documented reversion date rather than assuming today's number holds through year-end.

Deprecation is a price change too

It's easy to think of pricing changes as only about the number going up or down, but a model being marked legacy or deprecated is effectively a pricing event as well — it's the provider signaling that a newer, usually better-priced option now exists, and that the model you're on may eventually stop being available at any price. Treat a status change on any model page the same way you'd treat a rate change: as a prompt to re-evaluate, not background noise.

What this means for anything you've built

A cost estimate is a snapshot, not a contract. If your product has a hard-coded price assumption anywhere — in a spreadsheet, a pitch deck, a budget line — treat it as provisional and put a recheck on the calendar, especially for any model where you're relying on introductory pricing. Production systems that pass costs through to customers (usage-based billing, per-seat AI features) are the most exposed, since a silent provider price increase becomes a silent margin cut if nobody's watching.

• Track the models you actually use, not the whole market — a handful of models cover almost every production system.
• Note the source and verified date on any pricing number you rely on, and prefer numbers pulled live from a dataset over ones typed once into a doc.
• Recheck before any budget cycle, and immediately after you hear about a new model generation from a provider you depend on.

Every model in this dataset carries a source URL and a verified-as-of date — click through on any price you're relying on and confirm it against the provider's own page before you build a budget around it.

The practical takeaway

Don't memorize a price. Bookmark the model page, or track it inside a workspace that flags a change when it happens. The alternative — rebuilding your cost assumptions from scratch every time you get surprised by a bill — costs more time than checking would have.

It's also worth separating the two kinds of surprise: a provider changing its published price, and your own usage quietly growing into a higher-cost pattern. Both show up as "the bill went up," but only one of them is visible on a pricing page — the other only shows up if you're actually tracking spend against usage over time, not just checking prices in isolation.