Anthropic will reroute refused API calls to another model

A model refusal used to be a dead end in your app. As of July 24, Anthropic's API will quietly hand the request to a different model instead. The fallbacks parameter now supports a "default" mode that applies Anthropic's recommended fallback models by refusal category — which means safety refusals just became a routing decision with a billing consequence, and you should decide the policy yourself rather than inherit theirs.

What actually happened

Per the Claude Platform release notes, the July 24 update added "default" mode to the fallbacks parameter. Server-side fallback is in beta, and "default" requires the server-side-fallback-2026-07-01 beta header.

The mechanics matter. Anthropic's newer models run safety classifiers on the request and during generation. When a classifier declines, the Messages API returns stop_reason: "refusal" with a stop_details.category — cyber, bio, or reasoning_extraction (that last one covers Terms of Service restrictions on reverse-engineering model outputs). You aren't billed for a request refused before any output. The opt-in fallbacks parameter reruns that request on another model, billed at the fallback model's rates. It's available on the Claude API and Claude Platform on AWS, and not supported on the Message Batches API.

The same release put mid-conversation tool changes in beta — add or remove tools between turns while preserving the prompt cache, behind the mid-conversation-tool-changes-2026-07-01 header.

Why it matters for your business

We've written before about guardrails blocking legitimate security work. This is the vendor shipping a supported version of the workaround, and it's genuinely useful — a refusal in a customer-facing agent is an outage the customer sees.

But read the fine print before you set "default" and forget it. You are handing model selection to your vendor on a per-request basis, at a price you didn't quote, for the exact requests your classifier flagged as edgy. Three things to instrument: log every stop_reason: "refusal" with its category so you learn what your workload keeps tripping; pin an explicit fallback model rather than accepting the recommended one, so your outputs stay consistent; and put the fallback's token rates in your cost model, because refusal-heavy workloads now bill at a second price.

The tool-swap change is the sleeper. Rebuilding the tool list mid-conversation used to blow the prompt cache and re-bill the whole context. Preserving it means long-running agents that narrow their own permissions as a task progresses just got cheap. That's a real security pattern, not just a cost win.

Sources: Claude Platform release notes, Refusals and fallback docs.