AI Model Lifecycle: Your AI Stack Has an Expiration Date

The AI model lifecycle is the path every hosted model takes from release to retirement, and any workflow built on a model inherits that model's clock. Anthropic's model deprecations page names four stages: active, legacy, deprecated and retired. Once a model is retired, requests to it fail. The provider sets the schedule, not you, so the business question is simple: what in your workflow breaks when the model under it moves to the next stage?

TL;DR: Every model you build on will be retired. As of October 2026, Anthropic says it gives at least 60 days' notice before retiring a publicly released model, and the three most recent notices in its deprecation history each set retirement about two months out. The model ID is the visible dependency, but your prompts, parsers, tool calls, cost math and compliance checks all depend on how that one model behaves. Keep an inventory, a test set for each critical workflow, and a fallback you have tried. Then a retirement becomes a planned migration. For the deadline closest at hand, see the Claude Sonnet 4.5 retirement checklist.

The four stages a model moves through

Anthropic spells out its lifecycle vocabulary on its model deprecations page (opens in a new tab). As of October 2026, it defines the stages like this:

Two details on that page change how you should read it. First, Anthropic warns that deprecated models "are likely to be less reliable than active models," so the deprecated stage is not a safe place to wait. Second, an active model's retirement date is listed as "not sooner than" a given day. Claude Sonnet 5.5, for example, shows not sooner than September 28, 2027. That is a floor, not a promise of support after it.

Other providers use their own terms and their own schedules. Read each one's notices directly instead of assuming they match.

How short the clock runs

Anthropic's page says it gives "at least 60 days' notice before model retirement for publicly released models." The three most recent notices in the page's deprecation history show how close to that floor real schedules run. By our count from the dates on the page:

• Claude Sonnet 4 was deprecated April 14, 2026 and retired June 15, 2026: 62 days.
• Claude Opus 4.1 was deprecated June 5, 2026 and retired August 5, 2026: 61 days.
• Claude Sonnet 4.5 was deprecated September 30, 2026 and retires November 30, 2026: 61 days.

Two months is enough time to migrate one workflow carefully. It is not much time to discover that you have nine workflows on the old model and no tests for any of them. And the dates on Anthropic's page apply to its own platforms. Amazon Bedrock and Google Cloud "set their own retirement schedules," so the same model can retire on a different day depending on where you call it.

Argon and Sonnet tell one story

The last week of September 2026 compressed the whole lifecycle into a few days. Anthropic released Claude Sonnet 5.5 on September 28. Google announced Gemini 4 Argon on September 30, with an output limit of 1 million tokens. The same day, Anthropic deprecated Claude Sonnet 4.5 and named Sonnet 5.5 as its replacement.

New capability arrives fast, and yesterday's runtime becomes a legacy dependency just as fast. Neither event hurts a business on its own. A business whose logic only works on the model it happens to run today gets hit twice that week: a better option it cannot safely try, and a deadline on the one it has.

What expires first

Take a software company's support-ticket router. It reads each ticket, returns JSON with a category and a priority, looks the customer up through a CRM tool, and drafts a first reply for an agent to approve. The model ID appears once, in a config file. The model's behavior appears everywhere else:

• The prompt was tuned to how this model follows instructions. A model that reads the same words more strictly may stop drafting replies for tickets it now considers out of scope.
• The parser expects bare JSON. A model that adds a sentence before the JSON breaks it.
• The tool call depends on the model choosing the CRM lookup before drafting. A model that drafts first writes replies without the customer's plan.
• The budget assumes this model's token use per ticket. A model that writes longer replies changes the bill.
• The compliance check assumes this model declines to quote refund amounts. A model with different refusal boundaries may start quoting them.

That list maps onto five kinds of disruption: output drift, tool-use drift, cost change, compliance drift and, if nobody migrates in time, downtime. Of the first four, only the broken parser throws an error. A better model is not a drop-in replacement, because "better" was measured on someone else's tasks. Our post on model deprecation covers the three ways a model change reaches a feature and how to tell it apart from your own bug.

Match the controls to the risk

Not every workflow needs the same protection. A tiering like this one keeps the effort where a failure would cost the most:

A canary release sends a small slice of live traffic to the new model first, so a problem shows up on a few requests instead of all of them. The support router above sits in two rows at once, customer-facing and tool-using, so it takes the controls of both.

Six continuity controls

These are the controls that turn a forced retirement into a scheduled task. They run roughly in the order you would build them.

1. Keep an inventory. Every production model ID, the workflow it serves, its owner, its prompts, tools and data connections, and which platform it runs on.
2. Watch the notices. Route each provider's deprecation, pricing and policy notices to a named person. Anthropic says affected customers are notified by email and in its documentation, so that email has to land with someone who will act on it.
3. Keep a test set per critical workflow. Real tasks with known good outcomes, frozen so you can run them against any candidate model. Our guide to LLM regression testing covers how to score them.
4. Version everything around the model. Prompts, tool definitions, policies and output schemas, so you can tell a model change from your own edit.
5. Separate business rules from the prompt. Approval limits and routing rules belong in code or config the next model also reads. Our post on model-agnostic AI architecture shows where each piece lives.
6. Build and rehearse a fallback. A second model, a rollback path or a manual queue, set up before you need it, plus one practice migration before a deadline forces the first real one.

When the controls cost more than the risk

Designing for replacement is not free. A regression suite has to be written and maintained, and a fallback model has its own lifecycle, its own quirks and its own retirement date. A fallback nobody has tested is a second untested dependency. For a low-volume internal summarizer, the honest math may say that migrating by hand when the notice arrives costs less than a year of upkeep on the controls. For the support router, it almost certainly does not.

Where your own line sits depends on what a bad week would cost, and we cannot draw it for you. What we can say is that the decision should be made before the notice arrives, because a 61-day window is the wrong time to start the argument.

The advantage of a replaceable model

A company whose controls and tests already exist can adopt a better model in days, because adoption is a test run. A company without them meets every upgrade as a risky rebuild, so it is more likely to stay put until a retirement forces the move. For the support router, adoption means one frozen set of past tickets, scored against both models, before any live ticket reaches the new one. Portability is not about refusing to commit to a vendor. It is about keeping the ability to change when change arrives on someone else's schedule.

Pairs well with

The Ransomware & AI-Outage Recovery Readiness Drill ($79) grades whether you would recover from a critical AI-dependency outage, and forces WOULD NOT RECOVER when a load-bearing AI dependency has no fallback. The AI Vendor Reliability & Spend-Justification Scorecard ($79) scores each AI vendor on reliability and value and returns RENEW, RENEGOTIATE or DO NOT RENEW. The AI Agent Go-Live Readiness Gate ($79) rates five controls, including a tested rollback path, before an agent goes live.

More in this guide

• Claude Sonnet 4.5 Retirement: Your Migration Checklist
• Why AI Model Upgrades Break Production Workflows
• LLM Regression Testing: Prove a New Model Is Better
• Model-Agnostic AI Architecture: Keep Your Workflow Portable

What is the AI model lifecycle?

It is the sequence of stages a hosted AI model moves through from release to retirement. Anthropic names four: active, legacy, deprecated and retired. Once a model is retired, requests to it fail, so any workflow still calling it stops working.

How much notice do AI providers give before retiring a model?

It varies by provider. As of October 2026, Anthropic says it gives at least 60 days' notice for publicly released models, and the three most recent notices in its deprecation history each set retirement 61 or 62 days out. Check each provider's own notices.

Is a deprecated model still safe to use?

It still works until its retirement date, but Anthropic warns that deprecated models are likely to be less reliable than active models. Treat deprecation as the start of a migration, not a grace period.

Do Amazon Bedrock and Google Cloud follow the same retirement dates?

Not necessarily. Anthropic's dates apply to its own platforms, and it says Amazon Bedrock and Google Cloud set their own retirement schedules. Check the model tables for the platform you call.

Can I just switch to the recommended replacement model?

Changing the model ID is the easy part. A newer model can format output differently, choose tools in a different order, use more tokens or refuse different requests. Run your own test set through it before it takes live traffic.

Which workflows need the most protection?

The ones where a quiet change costs the most: customer-facing assistants, agents that use tools, regulated or financial workflows, and automations that run without a person checking each result. Internal summaries usually need only periodic testing.