October 8, 2026 is the scheduled start of public extended access for Claude Opus 4.1 on Amazon Bedrock. AWS’s lifecycle table lists the model as Legacy since July 8, with end-of-life on January 8, 2027. Teams still using it for production, evaluation or agent workloads need an exit plan.
For affected teams, the priority is migration before January 8, 2027—including scheduled jobs and recovery paths, not only live traffic. Choose a replacement that your account can actually use, then validate its behavior, routing and cost.
What extended access allows
The October milestone is part of an existing retirement schedule, not a newly dated announcement. Calendar calculation: October 8 to January 8 spans 92 days. That is planning time, not a guarantee of access through a particular cutoff hour; the reviewed documentation does not establish the transition timezone.
AWS’s Legacy rules block new customers and say existing customers may lose access after 15 days without use. Requests fail on or soon after EOL unless continued access has been privately arranged. Applications do not migrate automatically.
AWS’s lifecycle explainer also says quota increases are not expected to be approved during public extended access, and Legacy models cannot receive new Provisioned Throughput by model units. These are general lifecycle restrictions, not evidence that Opus 4.1 previously offered every capacity or customization feature.
Do not substitute Anthropic’s direct-API dates: its deprecation record says Opus 4.1 retired there on August 5, 2026. For teams managing both services, our Sonnet 4.5 API retirement guide covers another provider-specific deadline.
Find live traffic and dormant dependencies
Search deployed configuration, application routing maps, queued work, evaluation settings and scheduled jobs for the identifiers in AWS’s Opus 4.1 card:
anthropic.claude-opus-4-1-20250805-v1:0
us.anthropic.claude-opus-4-1-20250805-v1:0Include application inference-profile wrappers and dynamically assembled names. For each dependency, record its owner, AWS account, source Region, API, model/profile identifier, last use and fallback route.
Use CloudWatch runtime metrics by ModelId to establish invocation, error, latency and token baselines. Existing invocation logs can help identify callers, but logging is disabled by default. Missing logs do not establish that nothing ran.
Inventory implication: a monthly job or emergency fallback can outlive the traffic visible in a recent dashboard. Reconcile usage with configuration; do not treat an idle Opus 4.1 route as dependable recovery capacity.
Choose the model, API and geography together
The following are evaluation candidates, not tested drop-in replacements. Both AWS cards currently list Active status and no scheduled EOL.
Candidate | Documented integration | Decision to make |
|---|---|---|
Converse and Invoke on | Evaluate when retaining the current API is important. Protocol continuity does not establish equivalent outputs or tool behavior. | |
Base ID | Evaluate when seeking a current-generation Opus model. Confirm account eligibility and cumulative request/response changes before committing. |
For Opus 5.5, Anthropic’s access guide directs customers to the AWS console for current criteria; a public model listing is not proof of access. Confirm the production identity’s permissions, usable quota, required features and target API before a canary rollout.
Check destinations, not just prefixes. The Opus 4.1 card lists routing among three US Regions. The Opus 5.5 card describes its US geographic route as covering the US and Canada. Reusing a us. prefix therefore does not by itself prove an unchanged processing boundary.
Inspect the selected profile’s destination Regions against your requirements. AWS’s cross-Region guide distinguishes geography-bounded routing from global routing and specifies organizational-policy requirements. Do not silently switch to a global profile to make a request succeed.
Opus 5.5 needs more than an ID swap
Follow the cumulative Opus 5.5 migration guide through its 4.1-or-earlier section. Priority checks for Messages-format payloads—not a ready-made Converse recipe—include:
Replace manual thinking budgets with adaptive thinking and effort controls. Thinking cannot be disabled.
Remove non-default sampling parameters and assistant prefills. Forced
anyor named-tool choice is rejected; review workflows that depended on mandatory tool invocation.Dispatch response content by block type and preserve thinking blocks unmodified in tool loops.
Respect Bedrock exceptions: Opus 5.5 lacks structured outputs, including strict tool use, there. Validate tool inputs in application code. For computer use on Bedrock, use
computer_20251124, not the newer toolset.
Budget without assuming a price rise
AWS says extended-access pricing can change by provider. An Opus 4.1-specific extended-access rate could not be verified from the public AWS pricing material checked for this guide. That establishes neither a surcharge nor unchanged pricing. Obtain the applicable rate, effective date, Region, tier and private-offer terms.
For reference only, Anthropic’s list rates per million input/output tokens are $15/$75 for Opus 4.1, $5/$25 for Opus 4.6 and $4/$20 for Opus 5.5. They are not an account-specific Bedrock quote. The same page documents a 10% regional-versus-global premium for newer Bedrock Claude models; that is separate from Legacy pricing.
Anthropic’s migration documentation says the newer tokenizer may use roughly 1–1.35 times as many text tokens as pre-4.7 models, and thinking is billed as output even when hidden. Neither is a measurement of your workload.
Cost decision: compare total spend per successfully completed task, including cache writes/reads, retries and auxiliary services. A lower token rate can justify an evaluation; it cannot establish savings before that evaluation.
Define what completes the migration
Set an internal completion date before EOL and a named owner for each remaining dependency. Use these as rollout gates:
Acceptance: evaluate representative tasks for correctness, tool effects, structured-data validity, error rate, latency and total cost. A successful HTTP response is not proof that the intended action completed.
Canary: send a bounded share of traffic through the approved identity and routing configuration. Retain a tested recovery option that will still be available after retirement.
Closeout: remove Opus 4.1 references from scheduled jobs, queues, evaluation suites and rollback settings; verify that remaining traffic has an explained owner.
If no live or dormant dependency exists, document that inventory result; the headline alone does not require a migration project. If no replacement passes, escalate the failing criteria early and establish another Active-model or manual recovery path.
Methodology: AI-assisted reporting and analysis based on AWS and Anthropic documentation checked on October 8, 2026. No authenticated account, billing record or model workload was tested. Recommendations are planning guidance, not reported performance results.