Sonnet 5 kept its launch price, and our calculators missed it

What we got wrong

Sonnet 5 launched at a price Anthropic labelled introductory, along with a published date on which it would rise. We encoded that faithfully. The model's entry in this site's facts module carried the launch price, the higher price and the date the higher price was due to take over, and because every calculator on the site reads from that one module, every calculator began quoting the higher figure on the scheduled day — automatically, with no deploy and nobody watching.

Anthropic didn't raise the price. Its pricing page now lists the launch price as Sonnet 5's standard price and says the scheduled increase "will not occur." For weeks afterwards, this site overstated what Sonnet 5 costs in every tool that priced it: the token estimator, the caching and batch calculators, the model picker. Worse, a worked example on the subscription calculator's page had been priced at the higher rate from the day it was written. If you budgeted Sonnet 5 work with our numbers in that window, your estimate was too high.

Why careful design made it worse

The irony is that the intro-price field existed to prevent exactly this class of mistake. A promotional rate with an end date is easy to forget, so we made the end date data rather than a note someone had to remember, and let the code apply the change on time. That solved the problem we had anticipated — forgetting to apply an increase — and created its mirror image: the site applied an increase the vendor had cancelled, with complete confidence, because the code treated an announcement as a fact about the future. Automation is exactly as honest as its inputs, and a forecast is not an input you can automate.

The site's build-blocking freshness check didn't catch it either, and the reason is structural. That check refuses to ship a new build when the facts behind it haven't been re-verified recently enough. It has no reach into a site that is already deployed, and the deployed site went on doing arithmetic against a date that had passed. What eventually surfaced the error was the check doing its job on the next build: the facts had aged past their re-verification window, the build failed, and the full re-read of Anthropic's pricing page that followed found the price. The gate worked. It just worked late, and late is the wrong time for a price.

What we changed

The price itself. Sonnet 5's entry now carries a single standard price, re-read from the pricing page, with no scheduled change attached. The Sonnet 5 page says plainly that the launch price became the standard one, and the correction is on the site's change log with its date.

A new build failure. The build now fails whenever any introductory price's end date is in the past. It deliberately doesn't guess the outcome. It stops, and its message tells whoever is building to re-read the pricing page and record what actually happened — the price rose, the price stayed, or the terms changed. A human has to look before the site can ship again.

Tests that don't depend on a real model. The code that applies an introductory price still has tests, now run against a synthetic model rather than a real one. The code path stays correct for the next launch at an intro rate, and nobody is ever tempted to leave a real model's pricing stale just to keep a test passing.

The same rule for every announced date

The general lesson reaches beyond prices. An intro-price end date, a retirement date, a default that "will change" — each one is the vendor's plan as of the day it was announced. This site already treated retirements that way: the lifecycle table shows the earliest date a deprecated model can retire as a floor, not a promise, and says so. Prices hadn't been given the same caution. Now they have, and the build enforces it rather than relying on anyone remembering.

If you maintain anything that prices Claude usage — an internal chargeback model, a customer-facing cost estimate, a spreadsheet that finance trusts — the same fix applies at any scale. Store the date alongside the price, but make the date trigger a re-check, not a change. The intro-price guide covers building that into cost monitoring.

What else the re-check found

The same full re-verification turned up other drift. Some models' statuses no longer matched Anthropic's deprecation page. The usage tracker kept its own copies of the cache multipliers instead of reading them from the facts module, so it could never have followed a pricing change. And the calculators assumed one cache-read discount for every model — true when the site launched, and exactly the assumption that had to be rebuilt per model before Fable 5.1 and Opus 5.5 could be added at all. All of it is fixed, and our post on keeping a cost calculator honest carries a correction of its own.

If you used our numbers

Re-run them. The calculators now price Sonnet 5 at its standard rate — the same rate as Sonnet 5.5, which matters if you're choosing between the two. The move to Sonnet 5.5 costs nothing on the rate card; what it costs is in the request code, and the migration guide lists exactly what breaks.