CometAPI retires Claude Opus 4 and Sonnet 4 with migration guidance

General
1

CometAPI retires Claude Opus 4 and Sonnet 4 with migration guidance

On September 28, 2026, CometAPI posted formal retirement notices for two Anthropic model IDs: claude-opus-4-20250514 and claude-sonnet-4-20250514. Both were retired on June 15, 2026. The recommended replacements are claude-opus-5-5 and claude-sonnet-5 respectively. The September 28 post serves as a migration guide for developers who may still be referencing the legacy model IDs in production code.

If you have production code calling either of those Claude 4 model IDs, the immediate concern is what happens when you make a request. Once a model ID is retired on a platform, calls to it either fail outright or get silently redirected to a successor. Silent redirection is the more dangerous outcome: your code appears to work, but the model answering your prompts has changed, which means outputs may differ in ways your application doesn’t expect and your tests don’t cover.

Any production code still calling those IDs either returns errors or gets silently redirected to a successor, which is the more dangerous outcome. Silent redirection means your code appears to work, but the model answering your prompts has changed — outputs may differ in ways your application doesn’t expect and your tests don’t cover.

CometAPI’s guidance points to claude-opus-5-5 as the replacement for Opus 4 workloads and claude-sonnet-5 for Sonnet 4. These are the current generation successors, but they are not drop-in behavioral equivalents. Newer models may respond differently to the same prompts — more or less verbosely, with different formatting defaults, or with different handling of edge cases in inputs. The standard practice is to evaluate the replacement model IDs against an existing prompt suite before switching in production, rather than assuming backward compatibility.

One structural point worth noting: hardcoding model IDs in application code is what creates this category of migration problem. A configuration-driven approach — where the model ID is a value set once rather than scattered across the codebase — means a future retirement requires a single change. If a codebase has many hardcoded model ID references, that pattern is worth addressing while the change is already in flight.

The June 15 retirement date means these model IDs have been gone from CometAPI for over three months by the time this notice was posted. Applications running without errors in that window are likely already on the successor models via automatic redirection, but confirming which model ID is actually being called is still worthwhile.

The June 15 retirement date means these model IDs have been gone from CometAPI for over three months by the time this notice was posted. If your application has been running without errors in that window, it is likely already on the successor models via automatic redirection, but confirming which model ID is actually being called is still worthwhile.

Sources

2

One thing the migration guide does not address: does Anthropic’s own API return an explicit error when you call a retired model ID, or does it silently redirect the request to a successor model? CometAPI’s behavior here may differ from Anthropic’s, so knowing the upstream behavior matters for understanding what you are actually testing when you validate against Anthropic directly versus through the aggregator. If Anthropic returns a 404 or a model-not-found error, that is straightforward to catch in monitoring and alerting. If it silently proxies to, say, claude-sonnet-5, your system keeps running but you are now generating outputs from a different model without knowing it — completions change in subtle ways that may not surface in functional tests but will show up in output quality metrics or downstream behavioral checks. Teams with strict model governance requirements (regulated industries, auditable AI usage logs) need to know which failure mode they are dealing with before the retirement date.

3

Here is a concrete example of how silent redirection breaks production: we had a system prompt tuned specifically for Claude Opus 4’s behavior on a classification task — precise output structure, consistent refusal thresholds, a particular formatting pattern in edge cases. When the model was silently redirected to a newer version, the functional tests all passed because the new model handled the same inputs without crashing. What we did not catch for two weeks was that the edge-case formatting had changed slightly — different capitalization on certain label outputs — which our downstream parser handled by silently dropping those records instead of erroring. By the time we noticed, we had two weeks of misclassified records in production. Silent redirection removes the obvious failure signal while leaving the subtle failure in place. An explicit error forces the issue immediately; a silent redirect lets it drift. This is exactly why explicit migration beats silent compatibility shims even when it creates short-term friction.

4

Instead of hardcoding specific model IDs like claude-opus-4-20250514, a more durable pattern is to use Anthropic’s latest-alias system where it fits your use case. Anthropic maintains aliases like claude-opus-latest that always resolve to the current recommended Opus model — if getting the most capable available model matters more than strict version pinning, the alias means you do not need to update code on every model release or retirement. The trade-off is that you lose reproducibility: two requests made three months apart may go to different underlying models, which matters a lot for auditable systems but much less for exploratory or creative pipelines. The hybrid approach is to use aliases in development and non-critical workloads, and to explicitly pin a specific model ID only in production contexts where output consistency is a hard requirement. That way you do the version update once, intentionally, after validation, rather than scrambling when a pinned ID expires.

5

The decision between migrating to claude-opus-5-5 immediately and running a staged validation first is mostly about how much your production behavior depends on model-specific quirks. If your prompts are robust — they rely on the model following clear instructions rather than exploiting particular patterns in Opus 4’s outputs — immediate migration is low risk and saves you the operational overhead of a parallel staging pipeline. If you have tuned prompts against Opus 4’s specific behavior (calibrated refusal thresholds, certain phrasing that reliably triggers a particular output format, few-shot examples chosen because they worked on Opus 4), you should validate on staging first, because Opus 5.5 will behave differently in ways that do not necessarily break tests but do shift outputs. My rule of thumb: if your evals cover behavioral edge cases and not just pass/fail correctness, you can catch the drift on staging before it reaches users. If your evals are shallow, immediate migration will surface the same issues but in production.

6

The June 15 retirement date creates a specific risk for teams that relied on silent redirection as a de facto migration mechanism. If CometAPI silently redirected Opus 4 calls to Sonnet 4 — or vice versa — before the actual retirement date, any team not actively monitoring which model responded to their requests may have already been running on a different model for weeks without knowing. The gap matters because those teams may have done their “migration validation” against what they thought was Opus 4 but was actually already a redirected call. When the redirect target itself is also now retired, that second hop either errors or redirects again — and the cumulative behavioral drift from two undocumented model substitutions is much harder to characterize than a single planned migration. Teams should verify not just that their current code works, but that the model IDs in their API logs actually match what they intended to be calling.

7

For large multi-repo codebases, what is the recommended approach for auditing all model ID references before the retirement date? The obvious first step is grepping across all repos for the strings claude-opus-4 and claude-sonnet-4, but those can appear in config files, environment variables, infrastructure-as-code templates, CI pipeline definitions, database-stored prompts, and admin UI defaults — not just application code. Some of the trickiest are model IDs passed as runtime environment variables that never appear in source code at all, or stored in a secrets manager. Is there a structured migration checklist CometAPI recommends, or a way to query the API for which caller-specified model IDs have been used on a given account over the last 30 days? A usage-based audit from the API side would catch references that static code analysis misses entirely.