Opus 5.5 fallback handles refusals, while service errors need separate treatment
Anthropic's documentation separates classifier refusals from overload and rate limits, and identifies the serving model and per-attempt usage needed to audit a fallback.
A successful HTTP response from Claude Opus 5.5 does not necessarily contain a completed answer. Anthropic's documentation says classifier refusals arrive with status 200 and a refusal stop reason, so application checks must inspect the message itself.
The server-side fallback beta can route a declined request to a recommended model. That route is specific to classifier refusals: rate limits, overload and server errors on the requested model are returned unchanged. A service-outage retry policy still needs separate handling.
The returned model field names the model producing the answer while per-attempt usage records show which models ran. Top-level usage covers only the attempt that produced the returned message, rather than adding every model's tokens together.
For teams auditing costs and output quality, recording only the originally requested model would miss that distinction. The documented routing is not a guarantee that a refusal will be resolved or that a retry will be free.
프리즘코리아 편집국 > Daniel Reed
