If your production router still has Claude Opus 4.1 anywhere in its fallback chain, the quiet migration window is over. That branch now ends in an error.
Claude Opus 4.1 is retired, not merely deprecated
Anthropic has changed claude-opus-4-1-20250805 to Retired in its official model lifecycle table. The company’s August 5 platform release note is even plainer: all requests to that model now return an error.
This is the important change since the earlier warning. A deprecated model still works while teams migrate. A retired model does not. If a hidden job, old environment variable, or last-resort router branch still names Opus 4.1, traffic can fail the moment it reaches that path.
The Claude Opus 4.1 retirement timeline
Anthropic gave two months of notice. The model has now crossed from warning state to hard failure.
Deprecation announced
Anthropic warns active users and publishes an August 5 retirement date.
Claude Opus 5 launches
The newer model arrives with the same published token price as Opus 4.8.
Requests now error
Opus 4.1 is marked Retired. The migration is no longer optional.
The lifecycle page says these dates apply to Anthropic’s Claude API, Claude Platform on AWS, and Microsoft Foundry. Amazon Bedrock and Google Cloud operate their own retirement schedules. Check the provider table for each deployment instead of assuming one date covers every endpoint.
The first job is finding every copy of the old model ID
Changing the model in one application file is the obvious fix. It is also the easiest place to stop too early.
I would search the entire delivery path for both the full ID and any home-grown alias such as opus-4-1. Look in source code, environment variables, secret-manager values, infrastructure templates, CI jobs, batch workers, eval harnesses, queue consumers, router rules, feature flags, and example configuration copied into internal documentation.
Then inspect fallbacks. A team may have moved normal traffic months ago while leaving Opus 4.1 as the second or third option for capacity errors, refusals, or regional outages. That code can look healthy for weeks because nothing forces it to run.
Anthropic’s console can help: the deprecation page recommends exporting the Usage CSV and reviewing requests by API key and model. Repository search finds configuration. Usage data finds code that actually ran. You want both.
Opus 4.8 is the smaller bridge; Opus 5 is the newer destination
Anthropic gives two apparently different recommendations. The deprecation table points Opus 4.1 users to claude-opus-4-8. Today’s release note recommends claude-opus-5. I read that as a migration choice, not a contradiction.
Choose the route that matches the incident you are solving
Both are active models. The best emergency fix may differ from the best long-term architecture.
Claude Opus 4.8
- Anthropic’s exact replacement in the deprecation table.
- Useful when restoring service with the smallest behavior jump matters most.
- Supports web fetch and Priority Tier, which Opus 5 does not.
- Active with retirement listed as not sooner than May 28, 2027.
Claude Opus 5
- Anthropic’s recommendation in the August 5 release note.
- One-million-token context and 128,000 maximum output tokens.
- Thinking is on by default and the effort ladder needs fresh tuning.
- Active with retirement listed as not sooner than July 24, 2027.
If service is failing now and your test coverage is thin, Opus 4.8 is a sensible bridge. If you already have evals and can retest behavior, Opus 5 avoids scheduling another near-term model hop. Our earlier Claude Opus 5 routing analysis goes deeper on where the model earns its place.
A direct move to Opus 5 can fail for reasons beyond the name
The official migration guide has a direct Opus 4.1-to-Opus 5 section, but it sends developers through the cumulative breaking changes introduced along the way. Four deserve a deliberate test.
- Sampling controls: non-default
temperature,top_p, ortop_kvalues return a 400 error on newer Opus models. The fields can still type-check in an SDK, which makes this easy to miss before runtime. - Thinking configuration: manual extended thinking with
budget_tokensis no longer accepted. Opus 5 uses adaptive thinking and theeffortcontrol, with thinking enabled by default. - Token counting: Anthropic says the tokenizer used by Opus 4.7 and later may consume roughly 1 to 1.35 times as many text tokens as pre-4.7 models, depending on content. Recheck output limits, compaction thresholds, budgets, and alerts.
- Feature gaps: web fetch and Priority Tier are not supported on Opus 5. If either sits in your production contract, Opus 4.8 may be the practical immediate route.
At the published $5 per million input-token price, an illustrative one million old-model input tokens becoming 1.35 million would add up to $1.75 before caching and output costs. That is an upper-bound example, not a forecast. Run your own prompts because tokenization varies with the material.
Run a forced fallback-chain fire drill
A green test on the primary route proves only the primary route. Force the exact conditions that move traffic through every branch: capacity failure, timeout, refusal, region failover, circuit breaker, and batch retry. Watch which model ID actually receives the request.
The six-step retirement audit
The goal is not a successful demo. It is proof that no production path can still resolve to Opus 4.1.
Keep the failing Opus 4.1 call as a temporary negative test if your environment allows it. Your router should recognize the failure and recover exactly as designed. Remove the dead ID from production configuration once that behavior is proven so it cannot become a permanent source of latency.
This cutoff is also a reliability lesson
Model retirement is a predictable failure, which makes it a useful test of operational discipline. If a published date can surprise a production system, an unplanned model outage probably will too.
Keep model IDs in one controlled registry instead of scattering them across services. Give every entry an owner, provider, status, tested fallback, and review date. Alert on request errors by resolved model ID rather than only by product name. And make the fallback test part of releases, not a dashboard someone remembers during an incident.
That last point connects to our analysis of six Claude incidents and what they reveal about reliability. A fallback is not a resilience feature until someone has watched it work under forced failure.
My verdict: fix the dead route, then improve the router
The Claude Opus 4.1 retirement is now an operational event. Anthropic says requests to the model return an error. Teams still carrying the ID should restore service first, using Opus 4.8 as the lower-change bridge or Opus 5 as the newer destination.
Then spend another twenty minutes on the hidden paths. Search the repository. Export actual usage. Force every fallback. Remove sampling and thinking settings that newer models reject. Re-baseline tokens, latency, and cost.
The model-name edit takes seconds. Proving that no old branch can wake up under stress is the work that keeps this retirement from becoming an incident.
Go deeper
- Check Anthropic’s current model status and retirement table.
- Read the August 5 Claude Platform release note.
- Follow the Opus 4.1 to Opus 5 migration guide.
Did your Opus 4.1 reference live in the primary route, a fallback, or somewhere stranger?
Checked August 5, 2026. Anthropic’s model lifecycle pages can change as retirements are enforced. Provider-operated Bedrock and Google Cloud schedules may differ from Anthropic-operated endpoints.