Refusal fallback

When a safety classifier blocks a request, some providers can re-run it on a different model instead of returning a refusal.

Why it matters. Keeps legitimate work flowing, but the answer may come from a different model than you chose.

How it works

Refusal fallback is a provider behavior where, if a safety classifier flags a request to one model, a different model answers it instead of the API returning a refusal or error. The aim is to keep legitimate work moving when a classifier blocks something borderline.

Whether it exists, whether it is on by default and how the API signals it vary by provider and model. Check the response metadata, such as the model name or a flag, to see which model actually answered. The fallback model can differ in capability, price and limits.

Log which model answered each request, especially for evaluations and audits. If you need answers from one specific model only, check whether the fallback can be turned off.

Worked example

Illustrative: an agent on model X sends 1,000 security-research prompts; a classifier flags 30 and model Y answers them. An evaluation that credits all 1,000 results to X is wrong about 3% of them.

Common mistakes

Not logging the responding model, so results are credited to the model you requested.
Assuming the fallback model has the same context window, tools and price.
Treating fallback answers as evidence that the original model handles that domain.

See it on a real card: Safeguards on Claude Opus 5.5.