Model Deprecation Notices: What They Actually Tell You

A deprecation notice is a short document with a date in it, and almost everything that will consume your time over the following months is in what it omits rather than in what it says.

What a notice contains

Both major providers publish the same three columns and very little else. OpenAI’s deprecations page defines its terms plainly: deprecation is “the process of retiring a model or endpoint”, while sunset and shut down are used interchangeably to mean the model is no longer accessible. Its tables give a shutdown date, the deprecated identifier, and a recommended replacement. Anthropic’s model deprecations page publishes a status table with the API model name, its current state, the date it was deprecated and a tentative retirement date, plus a dated history of every past announcement.

The delivery mechanism is the same on both sides: customers with active usage are notified by email, and the page is updated. That has a consequence worth planning around. The email goes to whoever owns the account, which in most organisations is not the person who owns the service making the calls, and it arrives once. If your deprecation process depends on someone forwarding an email, it depends on a single human at a single moment, which is why a maintained calendar is a separate piece of work from reading the notice.

Deprecated is not retired

The vocabulary is precise and the distinction is the whole timeline. Anthropic’s page defines four states: Active, fully supported; Legacy, receiving no further updates and possibly deprecated later; Deprecated, still functional but no longer recommended, with a replacement named and a retirement date assigned; and Retired, no longer available, with requests failing. Deprecation is an announcement about the future. Retirement is when calls stop working.

Read the retirement column carefully, because the same table uses two different kinds of date. For models that have actually been deprecated, the date is a commitment. For models that are still active, Anthropic’s table expresses retirement as “not sooner than” a date — a floor on the model’s lifetime rather than a scheduled execution. Those two read almost identically in a table and mean opposite things for planning: one is a deadline you must beat, the other is a guarantee you may rely on until a real announcement replaces it. Copying a “not sooner than” date into your calendar as a deadline produces a migration nobody needed; copying it as a guarantee and forgetting to re-check produces the opposite mistake.

The notice period is a floor with an exception

Both providers publish a minimum. OpenAI’s deprecations page states that unless safety or compliance concerns require a faster timeline, it provides at least six months’ notice before retiring generally available models. Anthropic’s page states that it notifies customers with active deployments of upcoming retirements, providing at least sixty days’ notice for publicly released models.

Two qualifiers do real work in those sentences. “Generally available” and “publicly released” exclude preview, beta and experimental models, which is precisely the category people adopt early and then forget is different. And the safety-or-compliance escape hatch is not decoration: it is the mechanism by which a notice period can be shorter than the published minimum, and it applies exactly when you have least warning. Build your schedule assuming the floor, and build your architecture assuming the floor can be breached — those are different requirements, and the second one is what being able to run a second provider buys.

Five things the notice does not tell you

• Whether the replacement behaves the same. The “recommended replacement” column is a statement about capability tier and price band. It is not a claim that your prompts produce equivalent output. Nothing in a deprecation notice has ever been an equivalence assertion, and treating it as one is how a migration that was scheduled as a string change becomes an evaluation project.
• Which of your services call it. The provider knows your organisation used the model; it does not know that the call lives in a cron job in a repository nobody has opened in a year. That inventory is yours to build.
• Whether your parameters still work. Model retirements and parameter deprecations are tracked separately. Anthropic’s deprecations page carries its own table of API parameter deprecations, recording that temperature, top_p and top_k are deprecated for its newer models and return a 400 error when set to a non-default value. A model swap can therefore be a request-shape change too, and that failure surfaces as an HTTP error on the first call rather than as a quality regression weeks later.
• Whether the commercial shape changed. Price per token, context window, output cap, rate limits and typical latency are all properties of the replacement, not of the notice. A replacement that is better and twice the price is still a budget conversation.
• What date applies on your platform. This is the one most likely to catch a large organisation. Anthropic’s page states that its dates apply to Anthropic-operated platforms and that partner-operated platforms set their own retirement schedules, so the same model reached through a cloud marketplace can have a different lifecycle and a different date. If you call the same model two ways, you have two deadlines.

Turning a notice into work

A notice becomes a plan when you have answered five questions in writing. Which services call this model string, and how do you know — from a grep, or from logged request data? What is the date on the platform each of those services actually uses? What is your candidate replacement, and has it been run against your evaluation set rather than against the provider’s benchmark? Does the request shape need to change — parameters, response format, tool schema? And what is the last responsible start date, computed backwards from the retirement date through your evaluation cycle, your rollout ramp and one sprint of slippage?

That last number is the only one that matters on the day, and it is always earlier than people assume. If the notice period is sixty days and your evaluation cycle is two weeks, your ramp is two weeks and you allow a fortnight of slippage, you have about two weeks of genuine slack, not two months. The mechanics of holding those dates somewhere durable are in building a deprecation calendar for your stack, and the argument for pinning the version that gives you a date to hold in the first place is in the version-pinning strategy.