AI model deprecation: how to keep production running

AI model deprecation begins before an API stops responding. On September 30, 2026, Anthropic announced the retirement of Claude Sonnet 4.5 from the Claude API on November 30: 61 days in this case. The date does not identify the callers. Inventory, testing, and residual usage checks turn the notice into a verifiable migration.

Key Facts / Decision Matrix: Check the announced deadline against the contracted platform. Every dependency needs an owner and acceptance criteria. A recommended replacement still needs workload testing. Fallback protects against failure; it does not prove dependency removal.

The process has five steps, in this order:

1. Record the notice and the date applicable to the contracted route.
2. Find the applications still calling the model.
3. Prioritize dependencies and assign decision deadlines.
4. Evaluate replacements against workload criteria.
5. Migrate in stages and prepare a safe rollback.

After the change, the team checks residual usage by application. A model that still responds is no guarantee of time remaining, and a well-configured fallback does not prove that all callers have migrated. The LLM fallback guide covers availability during failures; here the problem is removing a dependency before a scheduled retirement.

What does AI model deprecation require?

The team needs documentation for the contracted route, call history with a known observation window, and access to application settings. It also needs business and engineering owners, a testing budget, and an authorized environment. Direct calls count. The inventory must reach requests made outside the gateway.

Before opening a spreadsheet, someone must confirm who can access logs, exports, and repositories, and how long each source retains its records. No record means no proof. A log that is unavailable for the required period represents a coverage gap, so the team cannot conclude that the application has stopped using the model. The team records the source, the available window, and the person who can confirm usage outside it.

The inventory covers production and other environments capable of sending relevant requests, integrations, scheduled jobs, and key identifiers. An identifier is not a secret. The record must not contain the key value, and access to test evidence must follow the organization's rules for the data involved. The business owner defines an acceptable result; engineering identifies the route and organizes the tests. Finance needs to know the budget available for evaluation.

Step 1: Record the notice and the date for your route

The notice record includes the URL, model and version, provider, contracted platform, scope, recommended replacement, and owner. The retirement date must correspond to the platform used by the application. Time and time zone may be absent. Leave them as GAP until the provider confirms them.

Anthropic's documentation distinguishes active, legacy, deprecated, and retired models. Under the company's definition, a deprecated AI model still works but is no longer recommended and has a retirement date; requests to a retired model fail. This behavior belongs to the cited policy and must not automatically be attributed to another provider.

For claude-sonnet-4-5-20250929, the September 30, 2026 notice and November 30, 2026 retirement date span 61 calendar days. The policy is specific. Anthropic states that it gives customers with active deployments at least 60 days' notice before retiring publicly released models. Neither figure establishes a typical market-wide deadline; that deadline is a GAP.

The date has an address. The documentation says its dates apply to platforms operated by Anthropic and that partner-operated platforms can follow their own schedules. The team checks the contracted route before copying a deadline into its plan and sets an internal deadline before retirement. That lead time is an operational decision, not a universal SLA.

Step 2: Find who still calls the model

The inventory reconciles calls logged in the gateway, provider exports, and references in code, configuration, and schedules. Each dependency gets an application, environment, secure key identifier, team, primary owner, replacement, and last observed call. The results must identify their sources and collection window.

A migration inventory is the reconciled record of applications, call identifiers, owners, observation window, and replacement status for every dependency on a model with an announced retirement. This is an editorial definition to guide the work, not a classification created by the provider. An unowned row stays open. Assign or escalate it.

For the Claude API itself, Anthropic recommends exporting Usage data and analyzing the CSV by key and model. The export helps locate usage in that API, but it does not prove that all company applications use it. Cross-checking gateway logs and configurations exposes differences between the sources; the article on LLM observability in production details the signals behind that analysis.

The window must cover normal operations.

A 30-day collection does not automatically cover monthly or quarterly jobs, or direct calls: the team compares the window with each workload's cycle and asks its owner to confirm usage. It records observed volume and the last observed call without turning missing records into zero volume. Insufficient history, expired retention, and unknown direct access remain GAPs.

The flow requires reconciliation. Dependencies without owners and direct access follow the exception branch until the team can resolve them. The diagram does not represent a product interface.

Step 3: Prioritize dependencies and set decision deadlines

Priority combines business impact, criticality, frequency, permissions, and the effort required to change each dependency. For every dependency, the team records who accepts the result, who makes the change, what evidence is missing, and when a decision is due. Escalate an unowned item.

The table is a fill-in template. NIST recommends inventorying AI systems according to organizational risk. It contains no real customers or results. The team uses one row per dependency, replaces the instructions with its own records, and retains the source and review date.

Frequency does not determine priority. An infrequent job can carry a delivery that cannot be repeated immediately, so its owner must assess the consequence of failure rather than just call volume. Access permissions and adaptation effort also matter: if the team cannot test a replacement in time, it must escalate that constraint before approving the change.

The decision deadline comes before retirement, leaving time to correct test failures and validate again. The team sets the margin for the workload and records who receives an escalation. No authorized number establishes that margin for every operation.

Step 4: Evaluate replacements before changing the route

The provider's suggested replacement is a candidate, not an approval. The team compares contracted access, modalities, context, tools, output format, parameters, privacy, quality, latency, and cost on authorized tasks. An unverified field is a GAP. Record the owner and test method before deciding.

When consulted on November 11, 2026, Anthropic's table listed claude-sonnet-5-5 as the recommended replacement for claude-sonnet-4-5-20250929. That recommendation does not demonstrate application compatibility, contracted pricing, or availability on the selected platform. Documentation changes. Confirm the details before publication and migration.

The workload owner approves the comparison criteria first, including the expected format, required content, latency limits, and handling of unsuitable responses. Engineering runs the same authorized real cases and relevant edge cases on the candidates and, where available, on the previous model; it records conditions, inputs, and results under the organization's security rules and compares the results against the approved criteria. Sensitive data need not appear in the report for the decision to be auditable.

Interface compatibility deserves a separate test. Anthropic's documentation says API parameters can be deprecated independently of models. The team therefore checks the parameters for the contracted route and fixes incompatibilities before increasing traffic. An accepted model name does not prove that its response meets the task's needs.

Step 5: Migrate in stages and prepare a safe rollback

Migration begins after access, budget, and acceptance criteria are confirmed. The team reviews the interface and parameters, sends an authorized sample to the new route, and monitors the result before approving gradual increases. This control is an engineering recommendation. It is not assumed to be a Router feature.

The route change needs an identified owner, a way to halt the rollout, and a record of the conditions for continuing. The team monitors errors, latency, consumption, and quality in the sample and compares the results with approved limits. If a criterion fails, it stops the increase and investigates before sending more traffic.

Rollback follows the calendar. While the previous model remains available, the team can maintain a rollback plan to it, provided that route is still authorized and the deadline allows its use. After retirement, a return to the discontinued model must not be promised. The alternative is another previously tested route or stopping the operation with an escalation path defined by its owner.

Fallback adds protection. The alternative must suit the workload. It neither identifies every caller nor replaces acceptance. Even when the alternative handles calls, the team must remove the retiring model dependency from the route configuration and verify that the change was applied.

How can the team verify migration completion?

Completion of an AI model migration requires reconciling recent calls by application and key, covering workload frequency, and confirming access outside the gateway. Each owner accepts the change and identifies the supporting evidence. Exceptions, tests, the window analyzed, and the review date remain with each dependency's status.

The change must show up. The team compares the original inventory with the sources and searches configuration, code, and schedules for the old model. If a residual call appears, it identifies the owner and returns that dependency for action. A change announced in a meeting is not a change applied to the route.

The metric's clock matters. A 30-day aggregate can retain calls made before migration; it does not need to reach zero immediately for a recent change to have occurred. Conversely, zero recent calls in a short window does not prove the absence of a quarterly job. For each workload, the team documents the appropriate window and confirms its cycle with the owner.

If a source does not cover the required period, or an application has direct access without reconciled records, completion remains conditional on resolving that GAP. Final acceptance brings together the applied change, the approved test, and the residual usage check across covered sources and windows, with exceptions and observation limits documented. Closing without that evidence trades a provider deadline for an undated open item.

How much does a pressured migration cost?

The estimate combines measured effort by role, measured incremental consumption, and other substantiated costs. It includes inventory, adaptation, validation, acceptance testing, observability, and security review, as well as replacement access and any degraded operation. Missing rates or measurements remain GAPs.

The working formula is: estimated cost = hours by role multiplied by the applicable cost + incremental consumption multiplied by applicable rates + other substantiated costs, without double counting. To apply it, the team assigns hours to the roles involved, records the basis for those hours, and separates test consumption from consumption that would have occurred without the migration. It also records any additional expenses it can substantiate. Forecast and observed values belong in separate fields.

The replacement price remains a GAP until the applicable rate is checked. Average migration cost, avoided losses, and the percentage of affected traffic are also GAPs in this guide; there is no authorized basis for filling them with a market number. A route that meets quality criteria can have different consumption and pricing from its predecessor, but the direction and size of the difference require workload measurement.

The cost-per-task study addresses a different question. It compares costs. In a migration, the questions before the calculation are whether the candidate performs the task and whether the team can make the change before the deadline. Without those records, a lower rate does not resolve the cost of a dependency that remains active.

Which errors threaten continuity?

To protect AI production continuity, the team must address unowned dependencies, sources that fail to record calls, and replacements accepted without testing. The response is to pair each symptom with a check and an action, a resolution deadline, and escalation to the responsible person.

The table does not end the investigation. If history is incomplete, the team records the source's limits and seeks confirmation in another source; if the replacement fails a quality, price, or latency criterion, the change is not accepted. The guide to fallback acceptance criteria addresses decisions at the interaction level; here, each application's dependency needs to be tracked through removal.

Frequently asked questions

AI model deprecation requires separate treatment of the notice, the route change, and proof that applications no longer depend on the model. The answers distinguish what the cited policy states from what still requires testing and confirmation by the responsible team.

What is AI model deprecation?

Under the cited Anthropic policy, it is the phase in which a model still works but is no longer recommended and has a retirement date. The consequence varies by platform. Anthropic's documentation says requests to retired models fail.

How can a team find who still uses a model?

The team cross-checks logs, provider exports, and application configurations, linking each observed call to a secure identifier and an owner; shared keys and aliases require further reconciliation. Include direct access and infrequent jobs. Cover the workload's full cycle, from production entry through its last seasonal flow, and record any coverage gap.

Is the recommended replacement compatible?

The recommendation identifies a candidate. It does not guarantee equivalence. The owner must confirm contracted access and test output format, parameters, quality, privacy, latency, and cost on the actual workload. Without measurement, record a GAP. The team needs evidence before deciding.

Does fallback resolve a deprecation?

Fallback can protect a route when the model fails, provided there is a configured alternative suited to the workload. It does not replace the inventory, replacement test, or confirmation that each dependency was removed. Rollback has a limit. It stops being an option when the application platform retires the old model.

When should the migration close?

Closure follows source reconciliation, verification over a window suited to each workload's frequency, and owner acceptance. Record exceptions, tests, and review. A short window without observed calls, by itself, does not prove that dependencies are gone.

References and further reading

Anthropic's official documentation supports the dated case and the limits of the policy attributed to the provider. The internal articles cited address availability, observability, fallback criteria, and cost per task from distinct perspectives. Check them again before publication.

The Anthropic deprecations page was consulted on November 11, 2026. The date depends on the platform. The inventory and acceptance procedures in this guide are editorial recommendations for the responsible team, not a description of specific provider tools or a promise of compatibility.

What should the team do next?

The team should open the inventory with the contracted route and assign an owner to each dependency before choosing the order of tests. The record must outlast the model change: it preserves the decision, the source of the date, and the evidence used to close the migration.

Nexforce Router is a model gateway with routing rules by key, spend limits, logs, metrics, tracing, alerts, and dashboards, plus configurable model fallback and provider failover. These features help track calls that pass through Router. Direct access needs another check. The features do not accept the change on the owner's behalf. The team remains responsible for testing replacements, confirming owners, and removing dependencies before the applicable date.