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.

When the scheduled change doesn't happen

The trap runs in the other direction too, and this site walked into it. Sonnet 5 launched at a price Anthropic called introductory, with an increase scheduled for a later date. When the date came, the increase didn't happen: Anthropic's pricing page now says the launch price is the standard price and the scheduled rise "will not occur." Anyone who had modelled the expiry as a certainty — including this site's own calculators, which switched to the higher rate automatically on the scheduled date — overstated Sonnet 5's cost until someone re-read the source.

The lesson is the same one this page makes about expiry, applied symmetrically: a stated end date is the vendor's plan at the time it was announced, not a fact about the future. Track the date, and on the date re-read the pricing page rather than assuming either outcome. This site now fails its own build when an introductory price's end date passes without anyone re-checking what happened. See Sonnet 5 kept its launch price for the full account.

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 the rate this site has verified as currently in effect, and every model page shows the date that verification happened — so check that date is after the expiry you care about before trusting the figure.