Simon Carter
Developer Tools & APIs

Anthropic removes fast mode from Claude Opus 4.7 and adds a 'default' fallbacks mode

From 24 July 2026, speed: 'fast' on Opus 4.7 returns a hard 400 error. Here's what to fix and what the new fallbacks default mode gives you.

Anthropic Claude platform documentation, vision example image used in official API code samples

From 24 July 2026, any API request to claude-opus-4-7 that includes speed: "fast" returns a hard 400 invalid_request_error. There is no silent fallback to standard speed, no retry that saves you. If your production code is still sending that parameter, it is breaking right now.

This is a narrow but sharp change. Here is what happened, what it costs you if you have not migrated, and what the new "default" fallbacks mode adds on top.

What changed with fast mode on Opus 4.7

Fast mode was deprecated on 25 June 2026, with a removal date of 24 July 2026. Anthropic has now followed through. The model itself (claude-opus-4-7) is still available at standard speed, so the removal is specifically about the speed: "fast" parameter configuration, not the model as a whole.

The error you will see is a 400 invalid_request_error, with a message along the lines of speed "fast" is not supported for model claude-opus-4-7. This matters for how you monitor it: it is not a 429 (rate limit) or 529 (overload), so any retry logic that catches those two codes will not catch this one. Your observability tooling will classify it as a client error, which means it can sit quietly in your logs unless you are watching for 400s specifically.

Where fast mode still works

Fast mode is supported on Claude Opus 5 and Claude Opus 4.8. Migrating to Opus 4.8 fast mode also comes with a meaningful price reduction: $10 per million input tokens and $50 per million output tokens, compared with $30/$150 on Opus 4.7. That is roughly a three-times cost reduction for the same speed-optimised configuration.

A few things worth knowing about fast mode before you migrate:

  • Fast mode is not a separate model. It is a different API configuration that prioritises speed, delivering responses up to 2.5x faster at a higher per-token cost than standard speed on the same model.
  • The first time fast mode is enabled in a conversation, you pay the full fast mode uncached input price for the entire conversation context up to that point. Enabling it from the start of a conversation is cheaper than switching mid-way through.
  • Setting temperature, top_p, or top_k to a non-default value returns a 400 on Opus 4.8, the same restriction that applied on Opus 4.7.

If you use Claude Code, switching to Opus 4.7 simply turns fast mode off, the same behaviour as any other model that does not support it.

The new "default" mode for the fallbacks parameter

Alongside the fast mode removal, Anthropic has shipped a "default" mode for the fallbacks parameter on the API. This is a separate feature, but it is worth understanding alongside the removal because it affects how refused requests behave.

Previously, the fallbacks parameter let you specify which model the API should retry a refused request on. The new "default" value hands that routing decision to Anthropic: it applies their recommended fallback model based on the refusal category, without you needing to maintain that mapping yourself.

How it works in practice:

  • If the primary model refuses a request, the API retries it server-side on Anthropic’s recommended model for that refusal category.
  • The fallback is triggered only by a safety classifier decline. A rate limit, overload, or server error on the primary model is returned as-is.
  • The response arrives with HTTP status 200, so the refusal is not an exception to catch in a try-catch block. Check stop_reason for "refusal" and inspect stop_details for the category.
  • To identify which model served a refused request, check the top-level model field in the response and look for a fallback_message entry in usage.iterations.

To use the "default" mode, set fallbacks to the string "default" and send the server-side-fallback-2026-07-01 beta header with your request. Server-side fallback is in beta on the Claude API and on Claude Platform on AWS.

A few limitations to note: the fallbacks parameter is not supported on the Message Batches API, and it is not available on Amazon Bedrock, Google Cloud, or Microsoft Foundry. On those platforms, use client-side fallback via SDK middleware instead.

The practical benefit of "default" is that you do not need to update your fallback configuration when Anthropic deprecates a fallback model. The routing is managed server-side and will be updated by Anthropic over time.

What you should do

If you have any integration calling claude-opus-4-7 with speed: "fast", the fix is straightforward: update the model string to claude-opus-4-7 to claude-opus-4-8 or claude-opus-5. The speed: "fast" parameter itself carries over without changes. You will also see a significant cost reduction when you do.

If you are using server-side fallbacks and want to simplify your configuration, switching to fallbacks: "default" removes the need to maintain a manual fallback model list and means Anthropic’s recommendations are applied automatically going forward.

Both changes are about reducing maintenance overhead over time. The fast mode removal forces an immediate action, but the "default" fallbacks mode is worth adopting proactively if you are already using server-side fallback.