The Retirement Email Isn't a Warning

The email arrives on a Friday. Your production workload is running on a model that gets turned off in 60 days. You have a workload to swap, an eval to build, a review chain to run through, and no protocol.

That's a fire drill. The deprecation exists as of the vendor's notice date, and the email only makes it visible to the team that should already have been ready.

The Deprecation Cadence Got Faster

For a long time, the working assumption was that a model you build on stays available for years, and that assumption no longer holds. Since October 2025, Anthropic has retired Sonnet 3.5 (both versions), Sonnet 3.7, Haiku 3.5, Haiku 3, Sonnet 4, and Opus 4, with Opus 4.1 going offline August 5, 2026 and Sonnet 4.5 losing support next September. That's roughly one retirement every six weeks for most of the past year, per the Anthropic deprecation page.

OpenAI's clock is on a different rhythm but the same direction. GPT-3.5 turbo, GPT-4, GPT-4-turbo, and o1 all shut down on October 23, 2026. GPT-5 shuts down December 11, 2026, less than eighteen months after it shipped. All of that is public on the OpenAI deprecations page.

There's also the extraordinary version. On June 12, 2026, Anthropic's Fable 5 and Mythos 5 went offline for most customers under an export directive, with Mythos Preview restricted to Project Glasswing partners and no standard notice period involved. If your workload sat on either model that day, you found out from the console, and the deprecation email sent months earlier hadn't been part of the story.

The published notice floors are 60 days from Anthropic and 6 months from OpenAI for generally available models, with preview and specialized variants getting shorter windows and export directives able to shorten those to zero. Every one of these windows counts down whether you're paying attention or not.

The Protocol

Six moves that turn the retirement email from a fire drill into a scheduled event.

• Read your vendor's deprecation policy today. Anthropic commits to a minimum of 60 days of notice on publicly released models, while OpenAI commits to at least six months for GA models, three months for specialized variants, and as little as two weeks for previews. If you don't know what your vendor's floor is, you can't plan around it. Both policies list every deprecated model with its retirement date and its recommended replacement, and both pages update as new deprecations get announced. Bookmarking them is a five-minute investment that catches every future change.
• Promote the model ID to a config. Every call site should read from one place, and in Python that's an environment variable with a default: MODEL_ID = os.getenv("PROD_MODEL_ID", "claude-sonnet-4-6"). Same pattern in any language. Swapping the production model then runs as a config change rather than a code change. Any pattern where the model ID gets inlined into API calls, sprinkled across services, or hardcoded into fine-tune targets is one that will hurt you the day the retirement email arrives.
• Build a small eval for every job that hits a model. Not a full test suite, but a representative 30-to-50 sample eval per job with a defined pass threshold. The eval is what tells you, in an afternoon rather than a week, whether the swap is safe. If you shipped the earlier Alcreon Playbook on the cheapest model that passes, you already have this asset. If you haven't, build one now for every job that touches a model. The eval is the load-bearing artifact of every future swap.
• Rehearse the swap monthly. Once the config is clean and the eval exists, running a swap rehearsal takes an hour. Point the config at the next-generation model, run the eval, and look at the pass rate. If it holds, the swap is confirmed safe. If it regresses, that's a signal to either fix the prompt for the new model or plan the fix inside the deprecation window. Doing this monthly, rather than once per retirement email, means every deprecation lands as a rehearsed play rather than a first take.
• Get the deprecation notification into a mailbox someone reads. Anthropic notifies "impacted customers with active deployments" by email, while OpenAI publishes to its deprecations page and emails account owners. If the notification goes to the billing account's default inbox and that inbox is unmonitored, the notice sits there while your countdown runs. Set up a filter that routes any subject line matching "deprecation," "retirement," or "sunset" to a channel your on-call engineer sees. Better still, subscribe your vendor-updates Slack channel to the RSS feed of the deprecations page directly.
• Negotiate the deprecation window in enterprise contracts. The published notice periods are the vendor's floor rather than their ceiling. Anthropic's 60 days is what they commit to for the public API, and both Anthropic and OpenAI can extend those windows in enterprise agreements. If your workload runs at meaningful scale and can't tolerate a two-month swap, negotiate a 180-day floor. That won't help against export directives, but it will cover every planned retirement your vendor announces.

A Scenario

A team runs an internal ops workflow on Opus 4.1 since it shipped in August 2025. The workload is customer-communication generation across ten workflows, 40,000 calls a day. They picked Opus 4.1 because it was the best model available for the workload's balance of quality, latency, and cost.

On June 5, 2026, Anthropic emails the account owner to say Opus 4.1 is deprecated with a retirement date of August 5, 2026, and recommends Opus 4.8 as the replacement. That's 61 days on the clock.

Team A has no protocol, and the email lands in a mailbox nobody reads for eleven days. The engineering lead notices it on June 16 because Opus 4.1 shows up as "deprecated" in the docs. They now have 50 days to grep the codebase for every place the model ID lives, pick a replacement, build an eval, run it, get approval, deploy, monitor, and roll back if something breaks. Two of those days go to the CTO wanting a written swap plan. Three more go to a legal-team question about whether the deprecation notice constitutes a service change under the master agreement. Two more go to a bug where a shadow deployment against Opus 4.8 leaks tokens because the new model's tokenizer is different. The team ships on July 23, with the last week a scramble to close out approvals and monitor the rollout.

Team B has the protocol in place, so their vendor-updates channel surfaces the notification the same Friday. The engineering lead points the staging config at Opus 4.8. The monthly eval runs the next morning, comes back at 96% pass on their standing 40-sample suite, and one flagged prompt gets a light rewrite. The team ships the swap by the following Wednesday. Total elapsed time: 5 days, of which about 4 hours was engineering work. The remaining 56 days of the notice window go to whatever else the team was building.

What separated the two teams was whether the protocol existed before the retirement email arrived. Skill and headcount didn't come into it.

Bad, Better, Best

• Bad. Model IDs hardcoded across a codebase you can't easily grep, no eval anywhere, and notifications routed to an unmonitored inbox. The team learns about deprecations from the docs page turning grey rather than from any planning process.
• Better. Model IDs live in a config file, referenced from three or four places, and a rough eval exists for the highest-volume job. Someone owns the vendor-updates inbox but reviews it weekly, so when a deprecation hits the swap takes days rather than weeks.
• Best. One config, one place, one swap, with a 30-to-50 sample eval covering every job and a defined pass threshold. Swap rehearsals run monthly and the results get logged. An enterprise contract extends the deprecation window past the vendor floor, and when the email arrives, the on-call engineer runs the rehearsed play in an afternoon.

Very few teams are at Best. Most teams sit between Bad and Better, and the retirement email finds them there. The move worth making this week is picking one job, promoting its model ID to a config, writing a 30-sample eval, and running one swap rehearsal against next-generation candidates. That's roughly four hours of work per job, and repeating across every job is how the protocol reaches the whole workload surface.

When to Skip

Not every workload deserves the protocol.

• Prototypes and one-shots. If the code will be thrown away in a month, don't over-engineer the swap.
• Personal projects. The retirement will still hit you, but the blast radius is limited to your own tolerance for evenings spent grepping.
• Workloads with under a few hundred calls a month. The deprecation is still a swap you have to make, but the eval overhead outweighs the swap risk. Just point at the recommended replacement when the notice arrives.

Everything else, treat as production. Every job that touches a paid model, runs on a schedule, or shows up on a dashboard is a job that a retirement email will find eventually.

Bottom Line

Deprecations aren't a rare failure mode anymore; they're a scheduled event, and you don't get to schedule them. The vendor does.

Config plus eval plus rehearsal is the loop that separates teams who handle deprecations from teams who scramble through them, and everything else is decoration. If you build one thing this week, promote your production model ID to a config and write a 30-sample eval for the workload that runs on it. The next retirement email will arrive when it arrives, and the team with the loop will spend an afternoon on the swap while the team without spends a month.