Start with what this mechanism is not, because the first reports you hear will get it wrong. It is not silent. Anthropic's announcement commits, in writing, to informing users whenever the fallback occurs. The consumer apps show a notice when it happens and label each response with the model that produced it. And on the developer API there is no automatic substitution at all: Anthropic states that a flagged request is blocked and returns a structured refusal, unless the developer has explicitly opted in to fallback. The suspicious first question — is the vendor quietly swapping models behind my back — has a documented answer. The answer is no.

The right question is more useful. Your organization already governs model changes: an upgrade is planned, validated, approved, and rolled out under change control. The Fable 5 fallback compresses that entire lifecycle into one API call. A request leaves your system addressed to claude-fable-5, and the answer may come back from claude-opus-4-8 — a different model with its own benchmark history and its own price. Anthropic reports that more than 95 percent of Fable sessions involve no fallback at all. That is the vendor's number, measured on pre-launch traffic, and nothing published at launch lets anyone outside Anthropic confirm it. So the executive question is not whether the switch is hidden. It is whether your team can say which model answered any given request, and what they do with the answer.

Walk one request through the developer API, because that is where governance becomes concrete. By default, a flagged request does not fall back at all. It is blocked, and the response carries a structured refusal: a stop reason of refusal and a category naming the policy area the classifier matched. Nothing answered you, and the response says why. Anthropic documents this as the API's default posture; substitution happens only when a developer asks for it.

Opting in is explicit. You name up to three fallback models in the request itself. If the first model declines and a fallback answers, the response object records the substitution: the model field reports which model produced the answer, a fallback marker shows where one model's output gave way to the next, a per-attempt record lists every try, and the refusal category says what triggered the handoff. “Which model answered” is a query against the response, not a feeling.

Two cautions ride along. A refusal arrives as an ordinary successful HTTP response, so monitoring built on error rates will never see one. And the classifiers run broad by design: Anthropic states the safeguards are deliberately cautious and will sometimes catch harmless requests, and on launch day a developer reported the safety notice firing during a routine code review of Lisp programs. The mechanism is disclosed and instrumented. It is not precise.

What makes this release worth your attention is not the fallback alone. It is the contrast shipped beside it. The fallback is disclosed three ways at once: the target model is named — Opus 4.8, a specific, documented, separately priced model, not an anonymous safe variant; a trigger rate is published, the vendor's more-than-95-percent-of-sessions figure; and the substitution is stamped into the API response. No prior production safety router shipped all three. OpenAI's September 2025 router disclosed the active model only when users asked and never published a rate, and its GPT-5 launch router fronted unnamed variants with no per-request disclosure at all. Paying subscribers revolted both times.

The same release carries a fourth safeguard with none of those properties. Anthropic's system card discloses that requests related to frontier-LLM development are handled differently: no fallback, no notification, capability quietly limited through techniques the card names, at a vendor-estimated rate of roughly 0.03 percent of traffic. That category appears in the system card and not in the announcement. By construction it leaves no trace a user could observe, which means the estimate cannot be independently checked — by you or by anyone else.

One release, one intervention class, two opposite disclosure postures. The governance work lives in the distance between them.

The discipline this mechanism requires is small, concrete, and buildable this week. None of it needs new infrastructure: a team that already logs requests and runs evals has every tool involved. Four steps.

Read the Fable 5 release as a preview of how frontier vendors will ship capability from now on: tiers, safeguards, and vendor-controlled substitutions, with the disclosure posture decided mechanism by mechanism. This time, the substitution you can see arrives with a name, a published rate, and an audit trail, while the one you cannot see is narrow and acknowledged only in the system card. The next release — Anthropic's or another vendor's — may distribute disclosure differently, and you will not get a vote.

That is why the discipline matters more than the mechanism. A disclosed fallback is governable: you can log it, measure it, challenge it, and put it in front of an auditor. A hidden degradation is only acknowledgeable: you can know it exists and price the uncertainty it adds. A team that logs who answered, treats substitution as change, measures its own rates, and segments its evals has the disclosed end covered today — and will be the first to notice when the spectrum shifts. The four steps above are small. The habit they build is not.