On April 14, 2026, Anthropic notified developers using Claude Sonnet 4 and Claude Opus 4: those versions would shut down on June 15. A two-month window. Anyone with a routine built specifically around that version had to test, adjust, and switch before the date — or stop working the next day.
It's not an isolated episode. According to Anthropic's own documentation, once a model version is retired, requests sent to it after the retirement date simply fail. OpenAI follows a similar logic: generally available models get a minimum of 6 months' notice, specialized variants 3 months, and preview models can go dark with as little as 2 weeks.
For whoever decides where AI runs inside a company, the relevant fact isn't the date itself. It's that a routine that worked yesterday can simply stop responding tomorrow — and the notice, when it arrives, lands on teams that already treat that workflow as part of daily operations.
Retirement Is Only Half the Problem
Anthropic classifies each model through four stages: active, legacy, deprecated, and retired. In the "deprecated" stage, a model still works but is no longer recommended — and it gets a retirement date. At the final stage, the API call fails outright. The public model table shows entire versions of Claude 3, Claude Sonnet 4, and Claude Opus 4 already offline in 2026, each with a notice date and a cutoff date on record.
OpenAI describes the same cycle with its own timelines: six months for a general-use model, three for a specialized variant, two weeks for something still in preview. In some cases, the company offers dedicated capacity under contract for anyone who needs to keep access to a specific version after shutdown — an option, not a guarantee.
Anthropic's public calendar shows the pattern repeating year after year: Claude Opus 4.1 was announced on June 5, 2026 and went offline on August 5 — exactly the 60-day minimum the policy promises. Before it, Claude 2, Claude 2.1, and other versions went through the same cycle. The timeline is public and predictable. The problem is that almost nobody inside a company is watching it until the notice email lands.
The second problem, less discussed, is that behavior shifts even when the model isn't retired at all. A study by researchers at Stanford and Berkeley compared the same AI service on two dates, three months apart, across seven task types: math, sensitive questions, opinion surveys, multi-hop reasoning, code generation, medical licensing exams, and visual reasoning. On one task — identifying whether a number is prime or composite — accuracy dropped from 84% in March to 51% in June, with the version label staying the same.
The study's authors put the finding plainly: the behavior of the "same" AI service can change substantially over a short period, which calls for continuous monitoring. In other words, waiting for a retirement notice isn't enough on its own. The version can stay online and still answer differently than it did three months ago.
Why the Notice Rarely Reaches the Right Desk in Time
The deprecation notice usually reaches whoever manages the technical connection to the model — not whoever designed the routine that depends on it. An email about a cutoff date two months out circulates among a handful of people, and the record of "why we do it this way" and "what this routine needs to deliver" is almost never written down anywhere.
When the date arrives, a question that should be simple — "what does this routine do, and what does it need to keep doing?" — has no ready answer. Someone has to reconstruct it from the output the routine used to produce, without knowing which instructions, examples, and adjustments got it there. That's reconstruction work, not a swap.
The same applies to the silent drift the Stanford and Berkeley study describes. Without a way to compare today's answer to the one from three months ago, nobody notices the drop until an error shows up in production — and when it does, the first instinct is usually to suspect whoever ran the routine, not the model version behind it.
For a company in Brazil or Latin America, the effect tends to land harder, not softer. The team that builds the AI routine is rarely the same one tracking each provider's version calendar — it's usually a business area, not a dedicated infrastructure team watching for this. When the notice arrives in English, with a cutoff two months out, the message competes with day-to-day operations and, often, only gets read after something has already stopped working.
What Has to Be in Place
The routine's script belongs to the company, not to a one-off conversation. What the routine should do, with which instructions, toward what result — that needs to live in a central record, not just in the memory of whoever built the first version.
Each task is routed to the right AI model, not pinned to a single one. Swapping the model behind a routine should be a configuration decision made in minutes, not a rebuild from scratch when the provider sends the shutdown notice.
Testing before switching is part of the process, not an extra step. Before a critical routine moves to a new model, the new version's output is compared against the previous one on the same cases — the same discipline the Stanford and Berkeley study recommends for any behavior change.
An audit trail shows what changed and when. When an output comes out different than expected, it's possible to check whether the cause was a model swap, an instruction change, or something else — instead of investigating blind.
This is how Skyller was designed: each routine's script and history are recorded on the platform, with automatic routing to the AI model best suited to each task, and an audit trail showing every change.
The Payoff of Not Tying Operations to a Single Model
When the script belongs to the company rather than to a specific model version, a deprecation notice becomes an operational event — configuration reviewed, output compared, routine cleared — instead of a crisis that demands rebuilding from scratch in a matter of weeks.
The same goes for silent quality drift. A team monitoring a critical routine's output catches the variation before a customer or an auditor catches it for them. And the record of who approved each version of the script stays available for any future review.
This doesn't remove the work of tracking the AI model market — no company escapes that. What changes is where the knowledge about the routine itself lives: on the platform the company controls, not only in the head of whoever built it, and not locked to one specific provider.
Questions to Bring to Your Next Technology Meeting
Before the next deprecation notice lands, it's worth answering these questions with whoever manages the company's AI routines:
- If the model behind the most critical routine went dark tomorrow, who knows how to rebuild it, and how long would it take? If the answer depends on one specific person, the script doesn't belong to the company — it belongs to them.
- Is there a way to compare today's output with the one from three months ago? Without that comparison, a quality drop only surfaces once it has already caused a visible problem.
- Is swapping the model behind a routine a configuration change or a project? If it's a project, every deprecation notice turns into an avoidable crisis.
