Plan model changes within deployment constraints

Learning objective

Account for model lifecycle and deployment constraints: pinned versions, deprecation and migration, platform availability, and data residency.

Core idea

A deployable model choice includes the exact ID, platform, required features, processing geography, and migration horizon. A model that wins an evaluation can still fail the deployment requirement because its platform lacks an endpoint or its hosting option cannot keep inference in the required geography.

Pinning and lifecycle management solve different problems. A pinned ID stabilizes the model snapshot; it does not make that snapshot available forever. Treat a replacement as a tested configuration change, and filter it through deployment constraints before spending time optimizing its quality and cost.

How it works

Pin the snapshot your evaluation tested

Anthropic documents every model ID as a pinned snapshot. From the 4.6 generation onward, dateless IDs such as claude-sonnet-5-5 identify that snapshot directly. They are not evergreen pointers. A changed model ships under a different ID.

Before that generation, IDs include dates, such as claude-haiku-4-5-20251001. The Claude API also accepts convenience aliases such as claude-haiku-4-5, which resolve to the most recent dated snapshot of that minor version. The snapshot guarantee applies to IDs, not those convenience aliases. Record the canonical ID in the production configuration and evaluation result.

The guarantee does not freeze serving infrastructure. Request routing, safety classifiers, and sampling infrastructure can change and produce minor observable differences on unchanged model weights. Continue representative evaluations after deployment; an unchanged model field does not prove that every observed behavior must be identical.

Operate the lifecycle explicitly

Anthropic defines four lifecycle states:

Anthropic gives customers with active deployments at least 60 days’ notice before retiring publicly released models. The published schedule applies to Anthropic-operated platforms: Claude API, Claude Platform on AWS, and Microsoft Foundry. Amazon Bedrock and Google Cloud set their own retirement schedules. A date copied from the Claude API table cannot establish a partner deployment’s deadline.

Find callers through the Claude Console Usage export, whose CSV breaks usage down by API key and model. Assign an owner to each affected route, choose a compatible successor, read its migration guidance, and rerun the route’s actual evaluation before retirement. For example, the Claude API schedule marks claude-sonnet-4-5-20250929 deprecated with retirement on November 30, 2026, and recommends claude-sonnet-5-5. That names a candidate, not proof that all request options remain compatible.

Keep the prior configuration available during a measured cutover only while its model is still available. A rollback plan pointing at an already retired ID cannot recover service. Include the remaining migration window when accepting a temporary fallback.

Check the platform and feature combination

Use each platform’s documented model IDs and supported features. Bedrock’s Messages-API integration uses IDs such as anthropic.claude-sonnet-5-5; Google Cloud uses claude-sonnet-5-5. Microsoft Foundry requests address the deployment name. A matching model family is not a portable endpoint configuration.

Feature gaps can reject an otherwise suitable model. Anthropic’s Bedrock, Google Cloud, and Foundry pages each list the Message Batches API as unsupported. The Bedrock Messages-API page also lists structured outputs as unsupported. If a route depends on a feature, verify that exact integration rather than importing the Claude API capability list into a partner deployment.

Google’s page calls the service Google Cloud Agent Platform and distinguishes global, multi-region, and regional endpoints. Global routing maximizes available capacity; multi-region routing stays within a geography; regional routing targets a specific region. Availability is model-specific: the page’s regional-endpoint samples note that specific regional endpoints support Sonnet 4.6 and earlier models.

Separate inference geography from storage

On the Claude API and Claude Platform on AWS, inference_geo accepts "global" or "us" for Claude 4.6 and later models. Global is the default. US-only inference costs 1.1 times standard token rates, including cache categories. Haiku 4.5 and other unsupported models return a 400 error if the request includes this parameter.

A default alone is overridable. To constrain a Claude API workspace, set data_residency.allowed_inference_geos to ["us"] and data_residency.default_inference_geo to "us" through the Console or Admin API. Requests asking for a disallowed geography fail. Inspect usage.inference_geo in responses to record where inference ran.

Workspace geo separately governs storage at rest and endpoint processing such as image transcoding and code execution. It is chosen at workspace creation and cannot be changed afterward. inference_geo: "us" is therefore not a complete statement about every processing and storage location.

Bedrock and Google Cloud select inference geography through endpoints or inference profiles rather than inference_geo. Bedrock regional endpoints and Google Cloud regional or multi-region endpoints carry a 10% premium over global endpoints for the models covered by those pricing rules. Foundry also does not use that parameter: deployments hosted on Azure can use US Data Zone Standard where the model supports it, with the same 1.1x US-inference multiplier as the Claude API. Sonnet 5.5 supports only Global Standard deployments on Foundry. A platform’s general residency option is not a promise for every model and hosting option.

Key distinctions and trade-offs

Pinning versus availability: A fixed snapshot prevents silent model replacement but still has a retirement schedule. Preserve reproducibility and plan migration together.

Geography versus region: A multi-region geography can satisfy a US-only requirement while failing a requirement for one named region. Match the endpoint’s actual boundary to the contract.

Default versus restriction: default_inference_geo supplies an omitted value; allowed_inference_geos limits what requests can choose. Use both when an override must not escape the policy.

Platform versus hosting option: Foundry’s hosting choice changes available features and deployment types. Inspect the actual model deployment rather than reasoning from the marketplace name alone.

Architecture / decision scenario

An education provider runs an instructor-feedback service on Foundry using Sonnet 4.5. A renewed customer contract adds US-only inference and separately reviewed storage arrangements. Sonnet 4.5 is hosted on Anthropic only in Foundry, whose hosting option offers Global Standard only, so the existing deployment cannot meet the added inference requirement. The platform owner proposes upgrading every deployment to Sonnet 5.5 because the evaluation improves rubric acceptance from a hypothetical 94% to 97%.

The architect rejects that blanket change: Sonnet 5.5’s Foundry deployment is Global Standard only. Copying inference_geo: "us" into a Foundry request cannot establish the missing boundary. Keeping Sonnet 4.5 fails the added geography requirement, and its retirement also requires migration.

The team instead evaluates Opus 5.5 on Foundry’s Azure-hosted US Data Zone Standard option, alongside Sonnet 5.5 on a Claude API workspace constrained to US inference. Both options carry the documented 1.1x US-inference multiplier. Sonnet adds a platform change; Opus has a higher base token price, so compare total accepted-result cost rather than attributing the premium to only one option. In the hypothetical replay, Opus reaches 98% acceptance within the provider’s budget. The data owner approves its storage and processing arrangements, and the architect selects that deployment to preserve the approved platform while meeting quality and inference-geography requirements.

The platform owner records the selected model ID, deployment name and hosting option, required features, and the schedule applicable to that platform. The release owner reruns acceptance and request-compatibility checks and completes cutover before the actual deployment’s retirement date. Better quality cannot waive the contract’s geography requirement.

Common exam traps

• Treating a dateless 4.6-generation-or-later ID as an automatically moving alias.
• Assuming pinned models never retire or never show infrastructure-related variation.
• Using Anthropic’s retirement date for a partner-operated platform without checking it.
• Treating a workspace default as an enforced geographic restriction.
• Equating inference geography with all storage and endpoint processing.
• Assuming every Foundry model supports US Data Zone Standard.

What to remember

Select a model snapshot within a specific deployable combination of platform, features, hosting option, and geography. Track retirement where the model actually runs, and test replacements before the deadline. Pinning preserves the evaluated snapshot; ownership and migration preserve service.

Knowledge check

References

• Anthropic, Model IDs and versioning
• Anthropic, Model deprecations
• Anthropic, Data residency
• Anthropic, Claude in Amazon Bedrock
• Anthropic, Claude on Google Cloud
• Anthropic, Claude in Microsoft Foundry