On 5 August 2026, Claude Opus 4.1 stops answering.
Not slows down, not degrades. Anthropic's documentation is unambiguous about what retirement means: a retired model "is no longer available for use" and "requests to retired models will fail". The date was published on 5 June 2026, when Anthropic notified developers using Opus 4.1 of its retirement, with Claude Opus 4.8 named as the recommended replacement. Anyone who built against that model and did not read the notice is out of runway.
This is not a story about one model. It is a story about a property of the AI stack that almost nobody has written into their operating model: everything in it has a published expiry date, set by the vendor, on a schedule you do not control.
The schedules are public, and they are busy
Anthropic publishes a four-state lifecycle. Active means the model is fully supported and recommended. Legacy means it will no longer receive updates and may be deprecated in future. Deprecated means it is still functional but no longer recommended, with a recommended replacement and an assigned retirement date. Retired means it is gone. On notice, the commitment is that Anthropic notifies customers with active deployments for models with upcoming retirements, "providing at least 60 days' notice before model retirement for publicly released models".
The recent history is not theoretical. Claude Sonnet 4 and Claude Opus 4 were deprecated on 14 April 2026 and retired on 15 June 2026. Claude Sonnet 3.7 retired on 19 February 2026. Claude Opus 4.1 was deprecated on 5 June 2026 for retirement on 5 August 2026. Claude Opus 5, released on 24 July 2026, already carries a published floor: not sooner than 24 July 2027.
OpenAI runs the same model of the world with different vocabulary and a longer runway. Its documentation defines deprecation as the process of retiring a model or endpoint, at which point it immediately becomes unavailable for new usage, with shutdown or sunset the point at which it is no longer accessible. The notice commitments are tiered: at least 6 months for generally available models, at least 3 months for specialised variants such as chat, Codex and deep research variants, and for preview models as little as 2 weeks, with the explicit caution that OpenAI does not recommend using preview models for business-critical production workloads unless you can migrate on short notice.
Its published calendar for the next six months is dense. Sixteen or more legacy GPT snapshots and Codex variants shut down on 23 July 2026. Two chat model snapshots follow on 10 August 2026. Older models including gpt-3.5-turbo-0125, gpt-4-0613 and o1-2024-12-17 shut down on 23 October 2026. GPT-5 snapshots and o3 models go on 11 December 2026. Legacy audio and realtime families follow on 20 January 2027.
The part that breaks people is not the models
Look again at that OpenAI calendar and notice what sits on 30 November 2026: the reusable prompts API, the Evals platform and dashboard, and Agent Builder.
Those are not models. They are the scaffolding teams built their AI operations on. An organisation that stored its prompt library in a vendor-hosted prompts API, ran its regression tests on a vendor Evals platform and assembled its agents in a vendor Agent Builder has three migrations landing in the same week, and none of them are fixed by switching model identifiers.
This is the gap between how deprecation is discussed and what it costs. Framed as a model change, it is a string replacement and a smoke test. Framed accurately, it is the retirement of components across the stack, on separate schedules, with different notice periods, and with the one component you would use to prove the migration was safe potentially retiring alongside the thing being migrated.
There is a second trap in the same documentation. Anthropic notes that its published dates apply to Anthropic-operated platforms, and that partner-operated platforms including Amazon Bedrock and Google Cloud set their own retirement schedules, so a model's lifecycle status and dates can differ. An organisation running the same model through a hyperscaler and through the vendor API is tracking two calendars, and the one it read is not necessarily the one that governs the integration that matters.
Parameters expire too. Anthropic lists temperature, topp and topk as deprecated for Claude Opus 4.7 and later, where setting them to a non-default value returns a 400 error. That is a working integration that starts failing because of an argument that used to be ordinary.
Why is this a governance question, not a developer chore?
For Australian regulated work, a forced migration has an awkward property: it is a change to a production system, with a deadline set by a third party, that you must make whether or not you have capacity.
That is a change management event. For APRA-regulated entities it sits squarely inside the CPS 230 obligations already engaged by AI providers as material service providers, a point we covered when the 1 July deadline caught up with AI vendors. The reason it deserves naming separately is that most change registers are populated by internal initiatives. A vendor retirement schedule generates change events nobody proposed, and if the register only knows about work the organisation decided to do, these arrive as incidents.
It also collides with validation. We have argued before that a passing pilot is not a passing production system because models change, data shifts and usage drifts. Retirement is the sharpest version of that: the exact artefact you validated is removed and replaced with one you have not. The replacement may be better on every published benchmark and still behave differently on your work, which is the whole argument for evaluating on your own tasks rather than the leaderboard.
There is an asymmetry worth stating plainly. Sixty days of vendor notice is generous by the standards of most software, and it is short by the standards of most regulated change processes. A change that needs a risk assessment, a test cycle against an evaluation set, a documented approval and a release window does not comfortably fit inside two months if the clock only starts when somebody happens to read a documentation page. The notice period is the vendor's obligation. The lead time is yours, and the only way to widen it is to learn about the date when it is announced rather than when it is imminent.
The same logic belongs in the contract. An exit or transition clause that contemplates the provider ending the relationship usually says nothing about the provider ending a specific model while the relationship continues, which is the far more likely event. Asking a provider to commit to a minimum notice period in writing, rather than relying on a documentation page it can revise, costs nothing at renewal and is worth having when a date lands badly.
And it is the twin of a problem we have already described. When Claude Sonnet 5 became the default, the risk was a silent swap under a workflow someone had validated. Deprecation is the same risk with the polarity reversed: not a change you did not notice, but a removal you were told about and did not action. The advice to pin a version answers the first problem. It does not answer this one. Pinning buys determinism, not permanence, and every pin should be entered in a diary alongside the date it expires.
What to actually do
Build the register, and make it broader than models. One row per AI dependency: the artefact identifier, where it runs, the published retirement date, the notice tier it falls under, the named replacement, the internal owner, and the workflows that break if it disappears. Include prompt stores, eval harnesses, agent builders, image and audio endpoints, and any vendor console your team treats as infrastructure.
Audit what you actually call, not what you think you call. Anthropic documents a path for this: export usage from the Claude Console and review the CSV to see usage broken down by API key and model, which is how you find the integration someone stood up last year and forgot. Every provider has an equivalent. The register is only as good as the discovery behind it.
Treat notice tier as a design decision. OpenAI's tiering is a gift if you read it as one. Building a business-critical workflow on a preview model is a decision to accept as little as two weeks of notice, and the vendor says so in its own documentation. That is a perfectly reasonable choice for an experiment and an unreasonable one for a regulated process, and the difference should be a written rule rather than an accident of whoever picked the model.
Schedule the re-validation, not just the swap. The migration date is not the retirement date. It is the retirement date minus the time needed to run your evaluation set against the replacement and fix what it breaks. Anthropic's own guidance is to test applications with new models well before the retirement date. For a workflow with any regulatory weight, that window is measured in weeks.
Watch the platform you actually use. If you run through Bedrock or Vertex, take the date from that platform's model table and not from the vendor's headline page.
The hype check
Deprecation is not evidence that AI vendors are unreliable. It is evidence that they are running capacity-constrained infrastructure and are honest about the consequence. Anthropic says so directly, noting that it currently deprecates and retires models to ensure capacity for new model releases, and it names the downsides in its own documentation: users who value specific models must migrate, researchers lose access for comparative studies, and retirement introduces safety and model welfare risks. It has committed to long-term preservation of model weights and says it hopes to make past models publicly available again.
Compared with most enterprise software, this is unusually transparent. The dates are published, the notice periods are stated, the replacements are named, and there is a documented way to audit your own exposure. The failure is almost never the vendor's disclosure. It is that nobody on the customer side owns reading it.
Bottom line
Every model, endpoint, parameter and console in your AI stack has an expiry date somebody has already published. The organisations that get hurt by this are not the ones with old models. They are the ones that cannot produce a list of what they depend on, and therefore find out on the morning the requests start failing.
Do this Monday
- Export your actual API usage by model from each provider console and compare it with what you believed you were running
- Build the dependency register, including prompt stores, eval platforms and agent builders, not just models
- Look up the published retirement date for every row, using the platform you actually run on
- Write the rule on preview-tier artefacts and where they may and may not be used
- For the two nearest dates, book the re-validation window now rather than the migration
TheAICommand. Intelligence, At Your Command.
