Claude 4 Deprecation in 2026: Migrate Sonnet 4 and Opus 4 Today

The Claude 4 deprecation lands today, June 15, 2026. As of this morning, Anthropic retires the two original 4.0 models: claude-sonnet-4-20250514 and claude-opus-4-20250514. API requests to either model name now return errors. Anthropic announced the schedule on April 14, 2026, gave 60 days of notice as their policy requires, and the recommended replacements are claude-sonnet-4-6 and claude-opus-4-8. If your production stack still hard-codes claude-sonnet-4-0 or claude-opus-4-0, your next call is the broken one. This post is the practical day-of migration guide for developers, agencies, and SaaS teams running the Anthropic API in production.

Quick Answer

• The Claude 4 deprecation hits June 15, 2026, retiring claude-sonnet-4-20250514 and claude-opus-4-20250514. API calls after the retirement window return failures, not graceful fallbacks.
• The one-line migration target is claude-sonnet-4-6 for Sonnet 4 traffic and claude-opus-4-8 for Opus 4 traffic. The API request format, the authentication header, and the response shape do not change.
• Claude Opus 4.1 (claude-opus-4-1-20250805) is the next domino; its retirement date is August 5, 2026, so the same migration plan should cover both waves.
• If you migrate to Opus 4.7 or 4.8, the temperature, top_p, and top_k parameters now return HTTP 400 on non-default values. Drop those fields and steer behavior through prompting instead.
• For teams that do not want to chase the next deprecation cycle, an AI app builder like Totalum keeps the Claude model id behind a managed integration, so the same project keeps shipping when the API string changes.

What the Claude 4 deprecation actually means

Anthropic uses a four-stage lifecycle for every model: Active, Legacy, Deprecated, and Retired. The Claude 4 deprecation refers specifically to the transition of the two 4.0 originals from Deprecated (announced April 14, 2026) to Retired (effective June 15, 2026). After retirement, the model name stops resolving on the Claude API, on Claude Platform on AWS, and on Microsoft Foundry. Partner-operated endpoints, Amazon Bedrock and Vertex AI, run their own retirement calendars and may keep the old model strings alive for a different window. Always check the partner platform's model table before assuming a unified cutover.

A retired model is not the same as a deprecated one. A deprecated model is still functional but unsupported and explicitly not recommended; a retired model fails closed. The Claude 4 deprecation is in the retired phase as of today.

The full Anthropic deprecation table for the 4 family

This table is taken from the canonical Anthropic deprecations page. Use it as the single source of truth for what is safe to call in production.

API model name	Current state	Deprecated on	Retirement date
claude-opus-4-8	Active	N/A	Not sooner than May 28, 2027
claude-opus-4-7	Active	N/A	Not sooner than April 16, 2027
claude-opus-4-6	Active	N/A	Not sooner than February 5, 2027
claude-opus-4-5-20251101	Active	N/A	Not sooner than November 24, 2026
claude-opus-4-1-20250805	Deprecated	June 5, 2026	August 5, 2026
claude-opus-4-20250514	Deprecated, retiring today	April 14, 2026	June 15, 2026
claude-sonnet-4-6	Active	N/A	Not sooner than February 17, 2027
claude-sonnet-4-5-20250929	Active	N/A	Not sooner than September 29, 2026
claude-sonnet-4-20250514	Deprecated, retiring today	April 14, 2026	June 15, 2026
claude-haiku-4-5-20251001	Active	N/A	Not sooner than October 15, 2026

Three observations matter for planning. First, every active 4-family model has at least one retirement date written into the calendar, so today's Claude 4 deprecation is not a one-off; it is the new normal. Second, Sonnet 4.5 retires September 29, 2026, only a quarter after Sonnet 4.0, so teams that just migrated from 4.0 to 4.5 already need a second migration in scope. Third, Opus 4.1 retires August 5, 2026, so the cleanest plan is to migrate both 4.0 and 4.1 in the same change window.

How to find every deprecated model string in your codebase

Before you touch the model id in config, audit where it actually lives. Production code rarely has a single source of truth, and most outages from a deprecation come from a forgotten serverless function or a half-archived microservice that still calls the old model name.

1. Grep your repos. Run a regex sweep across every service and configuration file for the deprecated model strings:

git grep -nE 'claude-(sonnet|opus)-4-(0|20250514)' -- \
  '*.py' '*.ts' '*.tsx' '*.js' '*.jsx' '*.go' '*.rs' '*.rb' '*.java' '*.kt' '*.swift' '*.env*' '*.yml' '*.yaml' '*.json' '*.toml'

1. Inspect the Anthropic Usage audit. In the Claude Console, open the Usage page, click Export, and review the CSV. The export breaks usage down by API key and model name, so any service still hitting claude-sonnet-4-20250514 shows up with both its hit count and the API key it is using. This is the canonical way to catch infrastructure you forgot about.

1. Pull from your observability layer. If you have request tracing (OpenTelemetry, Datadog, Honeycomb), filter spans for the anthropic.model attribute and group by value. Any non-empty group on a retired model is a live incident.

1. Scan deployed environments. Some teams leave the model name in an environment variable, not in source. Run a diff of your production env vars and your staging env vars to make sure the migration target is applied everywhere.

You will usually find more references than you expected. Centralizing the model id in one config variable is the easiest way to keep the audit cheap on the next round.

The one-line migration

The actual code change is shallow. For both Sonnet 4 and Opus 4, the request format, the authentication header, and the response structure are unchanged. You update the model identifier, run your evals, and ship.

# Before
client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarize this article."}],
)

# After
client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarize this article."}],
)

// Before
const reply = await anthropic.messages.create({
  model: "claude-opus-4-20250514",
  max_tokens: 4096,
  messages: [{ role: "user", content: prompt }],
});

// After
const reply = await anthropic.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 4096,
  messages: [{ role: "user", content: prompt }],
});

If your stack uses Anthropic SDK aliases (claude-sonnet-4-0, claude-opus-4-0), those alias strings now resolve to the retired model and fail. Replace them with the explicit current alias (claude-sonnet-4-6, claude-opus-4-8), or move the model id to a config variable so the next migration is a one-place edit.

What changed beyond the model string (parameters)

The migration is a one-line change in most cases, but there is one subtle gotcha. On claude-opus-4-7 and later, including claude-opus-4-8, the three sampling parameters temperature, top_p, and top_k are deprecated. The SDK still accepts them so existing code type-checks, but if you pass any of them with a non-default value the API returns HTTP 400. Anthropic's recommendation is to omit those parameters entirely and to steer model behavior through prompting instead. Existing prompts that relied on temperature: 0 to force determinism should be re-evaluated; the new recommendation is to specify explicit instructions in the system prompt and to leave sampling at defaults.

This parameter change does not apply to claude-sonnet-4-6. If you migrate Sonnet 4 traffic and leave Opus traffic on claude-opus-4-1 until August 5, you can keep your temperature and top_p fields. Once you move Opus to 4.7 or 4.8, drop them.

Testing the migration without breaking production

A one-line change is still a model change. Treat it like one. The three steps that catch the failures early:

1. Build an eval harness. If you do not already have one, pick the 50 to 200 representative requests that your service handles in a day and capture the current model output for each. Then re-run them against the new model. A diff tool is enough; you are looking for behavior shifts, not exact matches.
2. Canary the new model on a fraction of traffic. Route 5 to 10 percent of live requests to claude-sonnet-4-6 and the rest to the old model, then compare error rates, latency, and (if you have it) downstream conversion. The Anthropic API surface does not change, so the canary is a feature-flag away.
3. Watch the failure-mode metrics first. New models often shift the shape of their failures rather than the rate. A model that used to refuse hard prompts may now answer them, and vice versa. If you have guardrails downstream, run the canary through those guardrails.

For teams without an eval harness, the practical minimum is to record 24 hours of production prompts (with PII removed if applicable), re-run them against the new model offline, and have a human spot-check 30 samples. That catches more than 80 percent of behavior regressions.

Deprecated vs recommended models, side by side

The recommended replacements are not just newer versions of the same model. They have meaningfully different capability profiles and pricing. The migration is a chance to pick the right tier, not just to swap the suffix.

Model	Status	Indicative pricing per 1M tokens (input / output)	Context window	Notes
claude-opus-4-20250514	Retired today	Historical $15 / $75	200K	The original Opus 4. Production teams already moved most workloads off this in May.
claude-opus-4-1-20250805	Deprecated; retires Aug 5, 2026	$15 / $75	200K	Last of the high-price Opus tier. Migrate before August 5 to avoid a second outage.
claude-opus-4-8	Active	$5 / $25	1M	Recommended replacement. New temperature/top_p/top_k 400 rule applies. Strongest coding scores in the family.
claude-sonnet-4-20250514	Retired today	Historical $3 / $15	200K	The original Sonnet 4.
claude-sonnet-4-5-20250929	Active (retires Sept 29, 2026)	$3 / $15	200K	Plan to migrate again in Q3.
claude-sonnet-4-6	Active	$3 / $15	200K	Recommended replacement for Sonnet 4 traffic. Drop-in for sampling parameters.
claude-haiku-4-5-20251001	Active	$1 / $5	200K	Worth A/B testing against Sonnet 4.6 for low-complexity workloads; meaningful cost win when it holds up.

The Opus 4.8 price cut from $15 / $75 to $5 / $25 (a roughly 67 percent reduction) is the biggest reason most teams should migrate from Opus 4.0 or Opus 4.1 directly to 4.8, not to 4.5 or 4.6. If your bill is sensitive to Opus traffic, the migration also reduces it. We covered the detailed cost-per-task math in our Claude Opus 4.8 deep dive and again in Claude Opus 4.7 review for the transitional release.

Why Anthropic deprecates so fast

The deprecation also illustrates how Anthropic separates technical changes from commercial ones. On the same June 15 day the Sonnet 4 and Opus 4 IDs were burned, Anthropic paused the Claude Agent SDK credits program at the last moment. The retirements shipped. The pricing change did not.

The Anthropic deprecation page explains the pattern in plain language: retiring older models frees capacity for new model releases. A frontier lab cannot keep every snapshot of every model online indefinitely, because each one consumes GPU capacity that newer releases need. Anthropic's policy is at least 60 days of public notice before retirement for any publicly released model, and they email customers with active deployments on the affected model name.

The implication for builders is that the deprecation calendar is not slowing down. In 2026 alone, Anthropic has already retired or scheduled the retirement of Claude Haiku 3, Claude Sonnet 3.7, Claude 3.5 Haiku, Claude 3 Opus, the original Sonnet 4 and Opus 4 (today), Opus 4.1 (August 5), and Sonnet 4.5 (September 29). The shipping cadence on the active side is a release roughly every two to three weeks, including Claude Opus 4.6 in February, the Claude Fable 5 family and Claude Mythos 5 in June, and Claude Sonnet 4.6 in February. Anything that hard-codes a single Claude model string in production code has a planned outage built in.

Building model-version resilience

The cheap fix is to centralize the model id in one config value. The expensive fix is to centralize the abstraction. Both are worth doing, in that order.

Step one: pull every literal model string out of code and into a single environment variable or feature flag.

ANTHROPIC_MODEL = os.environ["ANTHROPIC_MODEL"]  # e.g. "claude-sonnet-4-6"

reply = client.messages.create(
    model=ANTHROPIC_MODEL,
    max_tokens=1024,
    messages=[...],
)

Step two: add a registry that resolves a logical name (primary-reasoning, summary, cheap-classification) to a current Claude model id and update only the registry when a deprecation lands. This is the same pattern most teams already use for database connection strings or third-party API keys.

Step three: stop owning the model registry yourself. This is where an AI app builder with managed Claude integration pays for itself. Totalum is its own AI app builder and shipped on the day Anthropic announces a new model; the underlying Claude model id is encapsulated in the Totalum platform, not in your project code. When Anthropic retires a model, Totalum updates its routing in one place, and the Next.js project Totalum built for you keeps shipping. You can read more about how the integration works in our Anthropic 2026 shipping cadence breakdown and in the best AI coding agents in 2026 roundup.

For comparison shoppers, our DeepSeek V4 Pro vs Claude post covers the case where you want a second-source frontier model in your stack so a single-vendor deprecation never takes the whole app down. That is a different kind of resilience and worth considering for any production system with hard reliability targets.

Agencies and SaaS teams: handling Claude migrations at scale

For an agency that ships and maintains client systems on the Anthropic API, the Claude 4 deprecation is not one migration; it is dozens. Every client repo with claude-sonnet-4-0 in it is a separate ticket. Two practical patterns help.

Pattern one: a shared model-router service. Build a small internal service that fronts every Anthropic call from every client project, exposes a stable internal API, and resolves the Claude model id internally. When Anthropic deprecates, you update the router once. We have seen agencies cut Claude migration cycles from two weeks across the portfolio to one afternoon with this pattern.

Pattern two: ship client projects on a managed builder. When the agency builds the client project on Totalum, the model versioning lives inside Totalum, not inside the client codebase. The agency does not have to revisit the client repo on every Anthropic deprecation, because the Claude integration is part of the platform layer, not part of the project. For an agency running 10 to 50 client engagements on the Anthropic API, that is the difference between maintenance work eating a week per deprecation and not noticing the deprecation at all. See our agency pricing context in Claude Code pricing in 2026 for how the cost math plays out across a portfolio.

If your agency is managing Claude API integrations across many clients and you would like to see how Totalum handles model versioning at the platform layer, book a call.

A 24-hour migration plan if you are reading this on June 15

If you have not started yet and your service is currently calling claude-sonnet-4-20250514 or claude-opus-4-20250514, here is the order to do things today.

1. Run the grep + Usage audit. Catalog every code path and every API key that hits the deprecated models. (15 minutes.)
2. Hotfix Sonnet 4 to Sonnet 4.6 in the highest-volume service first. Drop-in. Deploy behind a feature flag at 100 percent. (1 hour, including review.)
3. Hotfix Opus 4 to Opus 4.8 in any production service that needs Opus. Remove temperature, top_p, top_k overrides. Deploy behind a feature flag at 10 percent for a canary. (2 hours.)
4. Watch the canary. Compare error rate, latency, and response distribution. Promote to 100 percent if clean. (4 hours, including data collection.)
5. Sweep the rest of the portfolio. Migrate non-production services, scheduled jobs, and one-off scripts. Add a CI check that fails the build if a deprecated model string appears in repo. (Rest of the day.)
6. Plan the August 5 follow-up now. Opus 4.1 retires in 51 days, so file the ticket, write the test, and schedule the deploy window before you forget.

The teams that do this well do not treat the migration as a single push; they treat it as a recurring event with a checklist. Anthropic gave you 60 days last time and will give you 60 days next time. Use them.

FAQ

When does the Claude 4 deprecation take effect?

Today, June 15, 2026. After the retirement timestamp, API requests to claude-sonnet-4-20250514 and claude-opus-4-20250514 return errors on the Claude API, on Claude Platform on AWS, and on Microsoft Foundry. Partner platforms (Amazon Bedrock, Vertex AI) follow their own schedules and may retain the model names for a different window.

What replaces claude-sonnet-4-0 and claude-opus-4-0?

Anthropic recommends claude-sonnet-4-6 as the Sonnet 4 replacement and claude-opus-4-8 as the Opus 4 replacement. The request format, authentication, and response schema do not change.

Do I need to change anything beyond the model id?

For Sonnet, no. For Opus, yes. On Opus 4.7 and 4.8, the parameters temperature, top_p, and top_k return HTTP 400 when set to a non-default value. Drop those fields and use prompting to steer model behavior instead.

What about Claude Opus 4.1?

Opus 4.1 (claude-opus-4-1-20250805) is the next domino. It was deprecated on June 5, 2026, and retires on August 5, 2026. Migrate Opus 4.0 and Opus 4.1 in the same change window if you can.

How long is Sonnet 4.6 safe?

Anthropic's tentative retirement date for claude-sonnet-4-6 is not sooner than February 17, 2027. The earlier Sonnet 4.5 build retires September 29, 2026, so if you migrate to 4.5 instead of 4.6 you will be doing this again in Q3.

How can I avoid touching the model id on the next deprecation?

Centralize the model id in one config variable or registry, audit the Anthropic Usage CSV monthly, and treat deprecation as a recurring event with a tracked owner. For teams that do not want to operate the registry themselves, the Totalum platform encapsulates the Claude model id behind a managed integration, so the same Next.js project keeps running when Anthropic ships the next replacement.

Ready to stop chasing the next Claude deprecation?

Anthropic will deprecate claude-sonnet-4-6 and claude-opus-4-8 eventually. The next migration is on the calendar even if the date is not in your sprint plan yet. If you want a Next.js project that keeps shipping when the Claude model id changes, without your team rewriting code on a deprecation deadline, start with Totalum's free tier. Describe your idea, get a real Next.js project with auth, database, payments, file storage, and Claude integration included, and the model versioning becomes Totalum's problem, not yours.

Start free at totalum.app, or if you are an agency or SaaS team managing many Claude API integrations and want to see how the platform handles deprecation at scale, book a 30-minute call.