What you will be able to do
- Name the four Claude model lifecycle states and say what each one means for a running application
- Tell which platforms Anthropic's retirement dates apply to and which set their own schedules
- Plan a model migration using the notice period, the Console usage audit and pre-retirement testing
- Say what the anthropic-version header guarantees, and which feature classifications are safe to build production workflows on
Key concept
Model retirement — Every Claude model moves through a series of lifecycle states. A retired model stops serving requests altogether. Maintaining a Claude-powered system therefore includes planned migrations to replacement models, finished before the retirement date.
1.The four states a model passes through
With most dependencies, you choose when to upgrade. Claude models work differently: Anthropic retires older models as newer ones launch, so the model your application calls has its own life cycle, separate from your release schedule. The deprecations page says it plainly: applications that rely on Anthropic models "may need occasional updates to keep working." Anthropic notifies affected customers by email and in the documentation.
Anthropic describes four states. Active models are fully supported and recommended. Legacy models no longer receive updates and may be deprecated later. Deprecated models still work, but each one has a recommended replacement and a retirement date. Retired models are gone, and any request to one fails. The difference between deprecated and retired is the one that matters operationally: deprecation starts your migration window, and retirement ends it. Nothing reroutes your traffic automatically. If your code still names a retired model, it breaks.
| State | Meaning for your application | Example from the status table |
|---|---|---|
| Active | Fully supported and recommended for use | claude-haiku-4-5-20251001: retirement not sooner than October 15, 2026 |
| Legacy | No longer receives updates; may be deprecated in the future | (no model is listed as Legacy in the current table) |
| Deprecated | Still works; a replacement is recommended and a retirement date is assigned | claude-mythos-preview: deprecated June 9, 2026, retirement to be announced |
| Retired | No longer available; requests fail | claude-opus-4-1-20250805: deprecated June 5, 2026, retired August 5, 2026 |
Checkpoint 1 of 7· Check yourself
A nightly batch job still calls a model whose retirement date passed last week. What should the team expect?
A retired model cannot be used at all. Anthropic does not substitute another model, so the job fails until someone updates the model ID.
“Retired: The model is no longer available for use. Requests to retired models will fail.”Source: platform.claude.com
Sources1
2.Whose retirement schedule applies?
The dates on the deprecations page cover only the platforms Anthropic runs itself: the Claude API, Claude Platform on AWS and Microsoft Foundry. Amazon Bedrock and Google Cloud are run by partners, and they set their own retirement schedules. On those platforms, the same model can have a different lifecycle status and different dates. Each partner publishes its own model table.
| Platform | Operated by | Whose retirement dates apply |
|---|---|---|
| Claude API | Anthropic | The Anthropic deprecations page |
| Claude Platform on AWS | Anthropic | The Anthropic deprecations page |
| Microsoft Foundry | Anthropic | The Anthropic deprecations page |
| Amazon Bedrock | Partner | Bedrock's own model table |
| Google Cloud | Partner | Google Cloud's own model table |
For a team that serves the same application through several platforms, this means one deprecation notice can lead to several migration deadlines. Plan each deployment against the schedule of the platform it runs on, not against a single date.
Checkpoint 2 of 7· Exam question
Ahead of an upcoming retirement date, a platform team needs to find every place in their production traffic where a soon-to-be-retired model is still being called, broken down by API key and model, before they finalize their migration plan. Which action should they take in Claude Console?
Correct answer: C — Open the Usage page in Claude Console and export a CSV broken down by API key and model.
- A. Incorrect -- this bypasses the self-service audit tool Anthropic already provides and adds unnecessary delay compared to exporting usage data directly.
- B. Incorrect -- extended thinking is a reasoning feature unrelated to usage auditing and does not add model identifiers to a response payload for this purpose.
- C. Correct -- the Usage page's CSV export is the documented way to audit API usage broken down by API key and model, making it straightforward to locate deprecated-model traffic.
- D. Incorrect -- searching internal logs for a literal string depends on logging conventions the team controls and won't reliably capture every call broken down by API key and model the way the Console export does.
Checkpoint 3 of 7· Check yourself
Anthropic announces a retirement date for a model. Your team serves some customers through the Claude API and others through Google Cloud. What is true?
Anthropic's dates cover only the platforms it operates. Partner-operated platforms such as Google Cloud set their own schedules.
“Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ.”Source: platform.claude.com
Sources1
3.Running a migration before the deadline
For publicly released models, Anthropic gives customers with active deployments at least 60 days' notice before retirement. Use that window in a set order. First, find out where the deprecated model is still in use. The Claude Console has a usage audit for this: open the Usage page, click Export, and review the CSV, which breaks usage down by API key and model. That shows you which services and keys still need changing, so you can prioritise them.
Checkpoint 4 of 7· Put it in order
Put the Console steps for auditing deprecated-model usage in order
- 1.Go to the Usage page in Claude Console
- 2.Review the downloaded CSV to see usage broken down by API key and model
- 3.Click Export
The audit is an export from the Usage page. The CSV it produces is where you see which keys still call which models.
“Review the downloaded CSV to see usage broken down by API key and model.”Source: platform.claude.com
Next, test. Anthropic recommends testing your applications with newer models well before your current model retires, so you can measure how the replacement performs on your own tasks. Testing also catches breaking request changes, not only differences in output quality. For example, the Opus 5.5 migration guide notes that a manual thinking budget (thinking: {"type": "enabled", "budget_tokens": N}) is no longer supported on Claude Opus 4.7 and later and returns a 400 error. Request code that worked on the old model can fail on the new one, so read the model's migration guide before you change the model ID. Then update your code to the recommended replacement as soon as possible. Keep checking the deprecations documentation, and contact support if the migration stalls.
Checkpoint 5 of 7· Exam question
A platform engineering team runs a customer support application on Claude in production and wants to build a compliance policy for planning migration testing whenever a model they depend on is deprecated. Per Anthropic's stated commitment, what is the minimum notice period they can count on before a publicly released model they are actively using is retired?
Correct answer: B — At least 60 days before the retirement date
- A. Incorrect -- Anthropic's stated minimum commitment is 60 days, not 30, so a policy built around 30 days would assume less guaranteed lead time than Anthropic actually provides.
- B. Correct -- Anthropic notifies customers with active deployments at least 60 days before a publicly released model's retirement date.
- C. Incorrect -- 90 days overstates the guaranteed minimum; actual notice in specific cases has sometimes exceeded 60 days, but the committed floor is 60 days, not 90.
- D. Incorrect -- 180 days is well beyond the guaranteed minimum notice window Anthropic commits to for publicly released models.
Checkpoint 6 of 7· Check yourself
After switching the model ID from claude-opus-4-6 to a newer Opus model, calls that set thinking with a fixed budget_tokens start returning 400 errors. What is the right fix?
Manual extended thinking was removed on Opus 4.7 and later, so the request itself is invalid on the new model. The migration guide gives adaptive thinking, with the effort parameter, as the replacement.
“is no longer supported on Claude Opus 4.7 and later models and returns a 400 error. Switch to adaptive thinking”Source: platform.claude.com
4.API versions and feature classifications
Models are not the only part of the platform with a life cycle. Every API request must send an anthropic-version header, such as anthropic-version: 2023-06-01. The client SDKs send it for you. Within a version, Anthropic keeps existing input and output parameters intact. It may still add optional inputs, add output values, change the conditions for specific error types, and add new variants to enum-like outputs such as streaming event types. Code that handles every possible enum value strictly can therefore still break within a version. Anthropic recommends using the latest API version, and older versions may be unavailable to new users.
Features have their own classifications, and these decide what you can safely build critical workflows on. When a platform appears in a feature's Availability column with no label, the feature is stable, fully supported and recommended for production, with standard versioning guarantees. Beta features are previews: they may change significantly or be discontinued, and they are not guaranteed for ongoing production use. A Deprecated feature still works and comes with a migration path and a removal timeline. A Retired feature is no longer available. Features don't all pass through every stage, and a feature can enter at any stage.
Checkpoint 7 of 7· Match them up
Match each feature classification to what it means for a production workflow
Tap a term, then the definition that fits it.
Only unlabeled features carry full production and versioning guarantees. A critical workflow built on a Beta feature needs a contingency plan.
“Not guaranteed for ongoing production use.”Source: platform.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A deprecated model has stopped working, or will be swapped for its replacement automatically.Why is that wrong?
A deprecated model keeps working until its retirement date. After that date, requests fail. Nothing reroutes them, so you have to migrate yourself.
Covered in The four states a model passes through
2.Anthropic's retirement date applies to the same model on Amazon Bedrock and Google Cloud.Why is that wrong?
Anthropic's dates cover only the platforms it operates. Bedrock and Google Cloud publish their own schedules, which can differ.
Covered in Whose retirement schedule applies?
3.A Beta feature is as safe to build critical production workflows on as a stable one.Why is that wrong?
Beta features may change significantly or be discontinued, and they are not guaranteed for production. Only unlabeled features are recommended for production use.
Covered in API versions and feature classifications
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Applications relying on Anthropic models may need occasional updates to keep working.”
↩︎ The four states a model passes through“Legacy: The model will no longer receive updates and may be deprecated in the future.”
↩︎ The four states a model passes through“Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ.”
↩︎ Whose retirement schedule applies?“providing at least 60 days' notice before model retirement for publicly released models.”
↩︎ Running a migration before the deadline“Test your applications with newer models well before the retirement date of your current model.”
↩︎ Running a migration before the deadline“Once a model is deprecated, migrate all usage to a suitable replacement before the retirement date.”
↩︎ Key concept“Requests to models past the retirement date will fail.”
↩︎ Exam trap 1“The dates on this page apply to Anthropic-operated platforms: the Claude API, Claude Platform on AWS, and Microsoft Foundry.”
↩︎ Exam trap 2“The model is still functional but no longer recommended. Anthropic provides a recommended replacement and assigns a retirement date.”
↩︎ Prediction“Retired: The model is no longer available for use. Requests to retired models will fail.”
↩︎ Checkpoint“Review the downloaded CSV to see usage broken down by API key and model.”
↩︎ Checkpoint - 2.
“is no longer supported on Claude Opus 4.7 and later models and returns a 400 error.”
↩︎ Running a migration before the deadline“is no longer supported on Claude Opus 4.7 and later models and returns a 400 error. Switch to adaptive thinking”
↩︎ Checkpoint - 3.https://platform.claude.com/docs/en/api/versioningOfficial docs
“If you are using the client SDKs, this is handled for you automatically.”
↩︎ API versions and feature classifications“Add new variants to enum-like output values (for example, streaming event types)”
↩︎ API versions and feature classifications - 4.
“offers the feature as stable, fully supported, and recommended for production use”
↩︎ API versions and feature classifications“Feature is still functional but no longer recommended. A migration path and removal timeline are provided.”
↩︎ API versions and feature classifications“Features may change significantly or be discontinued based on feedback.”
↩︎ Exam trap 3“Not guaranteed for ongoing production use.”
↩︎ Checkpoint