Change the model, not the question

The rule sits in a reference table near the bottom of Anthropic's fallback-credit documentation, under a heading that reads like a compatibility note. When a Claude model declines a request and you retry it on another model, the retry is repriced only if it matches the refused request exactly. system, messages, tools, tool_choice, thinking and cache_control must be identical, along with output_config, mcp_servers, context_management and container where they appear. A second row lists the fields you are free to vary. It begins with model.

That table is the shape of the whole mechanism. An engineer whose request has just been refused has two ways forward. Ask a different model the same question, and the prompt cache already paid for is credited across, so the retry bills as though the conversation had been on the new model all along. Ask a better question — narrow the task, remove the ambiguity the classifier caught, split one request into two — and the exact-match rule is broken, the credit is forfeit, and a fresh cache is written at full price. Substitution is subsidised. Reconsideration is not.

Claude Opus 5.5, released on 22 September, is the first Opus model to ship into that arrangement. Anthropic's announcement says it launches with a similar class of safeguards to Fable 5.1 on cybersecurity, biology and distillation, "all of which fall back to another model transparently", and that while developers can still find and fix bugs as part of routine work, "most cybersecurity tasks will be re-routed to Opus 4.8". The plumbing predates the model: server-side fallback on refusal and a client-side middleware for platforms that lack it both landed in the Python SDK on 9 June, the fallbacks: "default" option followed on 24 July, and a change on 15 September went in only to clarify how each attempt is typed in the usage record. What arrived last week was not the capability. It was the first flagship with this economics underneath it.

The economics are worth reading closely, because they are unusually explicit. A refusal is not an error. It is an HTTP 200 with stop_reason: "refusal", empty content, and a category naming the policy area: cyber, bio, frontier_llm, reasoning_extraction, general_harms, or null. Three of those five are billed even when the model produced nothing at all, at the rates of the model that ran. The documented reason is precise: those are the categories where Anthropic "measures low volumes of false positives, as of September 2026", and the list "may change" as measurement continues. Declines under cyber and general_harms are free. So the price of being refused now depends on which policy the classifier thought you were near, and a switch over a policy taxonomy has quietly become a finance control in every caller that retries.

Around that sits a set of decisions that each look, individually, like generosity. Fallback credit exists so a customer does not pay twice to cache the same conversation. Sticky routing exists so a customer does not pay for an attempt that would predictably be declined again: once a conversation has fallen back, later requests go straight to the model that answered, for roughly an hour, keyed on a content hash of the conversation prefix and scoped to the organisation. The documentation is candid that this makes the event harder to see — a turn routed this way carries no fallback content block, because nothing declined it, so you identify it by the shape of usage.iterations instead. It even tells you what to instrument: a refusal is an HTTP 200, "so monitoring built on error rates or 5xx responses never sees it", and the thing to alert on is the gap between refusals and fallback-served responses.

This is careful engineering. It is more legible than the alternative that shipped before it, where a decline was a dead end and the caller's only recourse was a retry loop that paid for its own cache twice. And the case for charging is not cynical. An unbilled refusal is a free oracle: anyone mapping the boundary of a safety classifier at industrial scale wants exactly that, a cheap probe with a clean signal, and Anthropic says plainly that the billed categories are chosen to disrupt circumvention at scale. Any architect who has built admission control knows the shape of the argument. A free "no" is an invitation. That the billed set is three categories rather than all five, chosen by measured false-positive volume and published, is better behaviour than the industry norm, not worse.

The problem is not that the mechanism is hidden or greedy. It is what the mechanism makes cheap. Every affordance here reduces the cost of continuing: the credit, the middleware, the default fallback list, the one-hour routing memo, the single round trip. Not one of them reduces the cost of deciding — of concluding that the request was wrong, or too broad, or should have been narrowed, or should have gone to a person. The exact-match rule states the incentive almost as policy: the discount is for not changing your mind. Over a handful of requests this is a rounding error. Over an agent run with sub-agents, or a nightly batch, it is a gradient, and systems slide down gradients. Refuse enough requests, and a codebase learns that the standard response to a policy decision is a capability downgrade nobody reviewed.

The downgrade is not only a weaker model. Context is lost crossing the boundary. Extended thinking blocks from Opus 5.5 are dropped for every fallback target except Fable 5.1 and Mythos 5.1; on a mid-stream decline in streaming mode, only the partial output's text blocks are carried over to the model that continues. In a batch, a refused item returns as result.type: "succeeded", and server-side fallback is not available there at all. And the fallbacks parameter does not propagate into model calls made from inside tool execution, so in an agent that delegates, the substitution policy stops at the first hop unless someone threads it through by hand. The set of models a request may be diverted to is itself published as allowed_fallback_models on the Models API — but only when a beta header is set, and not at all on Amazon Bedrock, Google Cloud or Microsoft Foundry. On three of five platforms, the substitution set is a fact about your system that your system cannot read.

Which is why the published numbers deserve a second look. Opus 5.5's benchmark table carries a footnote saying the model was evaluated with production safeguards enabled, that when they intervened the cybersecurity tasks were completed by Opus 4.8 and the biology and frontier-LLM tasks by Opus 5, and that this "likely reduces" the reported scores. Zapier's AutomationBench run went the other way: no fallback models, so every safeguard intervention counted as a failure. Both are honest. They are also different measurements of different things, and neither is a property of one model. A score produced with routing on describes a policy; a score produced with routing off describes a model that, in production, many callers will never be alone with. The interesting number — how often the flagship answers your traffic at all — is not on anyone's leaderboard, because it depends on your prompts.

There is a way out of the loop, and it is the part practitioners should sit with longest. If benign work keeps tripping a classifier, the remedy on offer is not technical. It is accreditation. The Life Sciences Verification Program, opened on 17 September, grants vetted organisations access to work the generally available models block, after "a review of their research credentials, security standards, and ethical research oversight". Standard grants renew annually; high-risk grants, scoped to a single research project, renew every six months. A Cyber Verification Program with three tiers of increasingly permissive access is promised for Opus 5.5 in the coming weeks.

Read that as architecture rather than as policy and something unfamiliar appears. The capability your system depends on now has a renewal date — not a version, not a deprecation window, a renewal date, contingent on a periodic review of your institution. Architects know how to reason about a model being retired; the calendar is published and the migration guide comes with it. Rather fewer have a place in the design for a capability that lapses because a grant was not renewed on time, or that differs between two teams in the same company because only one of them was vetted, with the weaker model quietly answering for the other.

None of this is inferred from behaviour. It is all in one vendor's own published record — the release announcement, the platform documentation, the SDK changelog — and that record is the only evidence this argument rests on. Anthropic documents the mechanism more fully than most providers document anything, which is exactly what makes the gap legible: every field needed to reconstruct what served a request exists, and not one of them is aggregated anywhere by default.

So the honest version of a modern deployment note is no longer "we run on Opus 5.5". It is "we ask for Opus 5.5, and here is the share of last week's turns it actually answered". Model identity has quietly stopped being configuration and become telemetry — a measured property of production, drifting turn by turn, with an hour-long memory and a price attached to the moment it changes. The decision record in your repository still says the first sentence. Nothing in your dashboard yet says the second.