Anthropic Fallbacks "default" Mode Reaches Opus 5 — and Opus 4.7 Fast Mode Is Now a Hard 400 Error

Two things changed in the Anthropic API on July 24 that routing teams should verify in their configs today.

The first is a live-breaking change: speed: "fast" on claude-opus-4-7 now returns a hard 400 error. It no longer falls back to standard speed like the older Opus 4.6 did. Any production path that hardcodes fast mode on Opus 4.7 has been silently erroring for four days.

The second is a routing primitive that expands what was previously a Fable-5-only feature: fallbacks: "default" — Anthropic's curated server-side fallback by refusal category — is now available on Claude Opus 5 and Claude Opus 4.8, the two models most teams use for production agentic workloads.

What broke: Opus 4.7 fast mode is a hard error, not a graceful degradation

Anthropic's fast mode history across the Opus line is asymmetric and worth knowing:

The key operator consequence: Opus 4.7 does not degrade gracefully. If your gateway config has speed: "fast" pinned to claude-opus-4-7 in any code path — an environment variable, a model config file, a routing policy table — you are generating 400s rather than serving responses. The model itself remains available at standard speed; only the speed parameter is rejected.

Migration path:

# Before (now returns 400 on claude-opus-4-7)
{
  "model": "claude-opus-4-7",
  "speed": "fast",
  ...
}

# After: promote to Opus 5 or Opus 4.8 to keep fast mode
{
  "model": "claude-opus-5",
  "speed": "fast",
  ...
}
# OR: drop speed parameter and use Opus 4.7 at standard speed
{
  "model": "claude-opus-4-7"
  # no speed parameter
}

If you use the anthropic SDK middleware, check whether your speed field is set at the SDK layer or in environment config — SDK-level defaults can persist across model upgrades.

What's new: fallbacks "default" mode now works on Opus 5 and Opus 4.8

The server-side fallback API lets you declare a fallback model in the request itself. Instead of catching a stop_reason: "refusal" response and retrying with a different model client-side, the API handles the retry in a single round-trip. The response you receive comes back from either the primary model or the fallback, with no extra latency budget for your retry logic.

The "default" mode — where Anthropic picks the recommended fallback by refusal category rather than you specifying a model name — previously existed on Fable 5 and Mythos 5. As of July 24 it is also available on Opus 4.8 and Opus 5:

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "..."}],
    fallbacks="default",
    betas=["server-side-fallback-2026-07-01"],
)
# response.model tells you which model actually served the response
print(response.model)

The same pattern works in curl, TypeScript, Go, Java, PHP, and Ruby — the beta header server-side-fallback-2026-07-01 is the unlock, and fallbacks: "default" is the mode.

What "default" actually does: Anthropic routes refused requests to its recommended fallback per refusal category. Categories with no recommended fallback return the refusal as-is. You do not control which model handles the retry — that is the tradeoff for zero added client complexity. If you need to specify the exact fallback model, the explicit form (fallbacks: [{model: "claude-sonnet-5"}]) remains available.

The routing architecture implication

These two changes pull in opposite directions but point at the same operator lesson.

Opus 4.7 fast mode shows the cost of stale model config: a parameter value that worked last week now silently generates errors. The fix is one config line, but the damage (4+ days of 400s) happened because nobody caught it.

fallbacks: "default" on Opus 5 shows what thoughtful forward path handling looks like: a single parameter that tells the API what to do when the primary model declines, without requiring you to maintain your own retry logic or hardcode fallback model names that will themselves require rotation.

The combination is an argument for routing policies that are explicit about model lifecycle — rather than assuming that a parameter that works today will work after the next API release.

What to check in your routing config today

1. Audit fast mode settings: Search your codebase and config files for speed.*fast or "fast-mode". If any path targets claude-opus-4-7, remove the speed parameter or promote the model to Opus 4.8 or Opus 5.

2. Verify error handling for 400s: If your gateway treats all 400s as hard failures without inspecting the error body, you may be silently dropping requests rather than routing them to a fallback. Add explicit handling for speed parameter errors.

3. Evaluate fallbacks: "default" for Opus 5 workloads: If you are running Opus 5 for agent tasks that hit content classifiers (document analysis, summarization, agentic browsing), the "default" fallback mode is now available without additional model management overhead.

4. Check response.model in your logs: When server-side fallback is active, the model field in the response will differ from what you sent. Ensure your billing reconciliation and observability pipelines read response.model rather than assuming the request model matches the response.

For the full server-side fallback setup, including billing credit behavior for prompt cache hits on a refused primary call, see the earlier TheRouter analysis and the Anthropic refusals and fallback docs.