What changes when an intro price expires

Why an intro price is worth tracking as its own event

A newly released model sometimes ships with a temporary, promotional per-token rate lower than its standard price, valid until a stated date. That's a genuine, real discount while it lasts — and also a cost cliff waiting on the calendar, one that a budget built during the promotional window without accounting for its expiry will quietly stop reflecting reality the day it lapses.

The trap of budgeting against the promotional rate as if it were permanent

It's an easy trap to fall into precisely because nothing forces you to notice the distinction at the time — a cost estimate run during the promotional period, using the rate that's live at that moment, looks completely accurate when you run it. The problem only surfaces later, once the promotional window closes and the same workload that was accurately estimated a few months ago starts costing meaningfully more, with nothing about the workload itself having changed.

Where this bites hardest

The teams most exposed to this are the ones that did the sensible thing and built a careful cost projection early, using real numbers rather than guessing — and then didn't revisit that projection once the intro rate actually expired. A projection that was genuinely rigorous when it was built can still become quietly wrong through no fault of the original analysis, purely because one input to it had an expiry date that wasn't tracked as a follow-up item.

Building expiry into your cost monitoring

If a model you're using carries a promotional rate, note its expiry date somewhere your cost monitoring will actually surface again — a calendar reminder, a check built into whatever periodically reviews spend — rather than relying on remembering it from when the model first launched. A rate change that happens automatically, with no action required on your part to "trigger" it, is easy to forget precisely because nothing you do causes it; it just happens on its own on a fixed date whether or not anyone's tracking it.

Deciding whether to stay or migrate before the expiry, not after

The expiry of a promotional rate is also a natural moment to re-evaluate whether the model that carried it is still the right choice at all, rather than assuming you'll simply keep using it at the standard rate by default. If the promotional pricing was part of what made a particular model the obvious pick when you adopted it, it's worth explicitly re-running that comparison against the current lineup at standard rates before the expiry date arrives — not as a snap decision made the day the price changes, but as a deliberate check with enough lead time to actually act on the result if a different model turns out to be the better fit under standard pricing.

Communicating the change if you're passing cost through to others

If your own product's pricing to its users is built, even loosely, on top of what a model costs you, a promotional rate expiring upstream is worth communicating deliberately rather than letting it show up as an unexplained margin change nobody flagged. A cost increase you saw coming and priced for internally lands very differently than one that surfaces first as a surprise in your own numbers weeks after the fact.

Re-running your numbers once it lapses

Once a promotional rate expires, treat it as a genuine re-budgeting event, not a minor adjustment — re-run your cost projections using the standard rate rather than assuming the percentage difference is small enough to ignore, since the actual gap between promotional and standard pricing varies by model and isn't safe to assume is negligible without checking. The subscription vs API cost calculator and token & cost estimator both price against whichever rate is currently in effect for a given model, so re-running your numbers there after an expiry date reflects the real current cost rather than a stale promotional one.