Less restrictive is now a model spec

Anthropic launched Opus 5 this week, and past the usual cheaper-and-faster headlines is a change in how models are specified that enterprise procurement and audit teams need to sit up for. Per the launch coverage: Opus 5 is smaller and cheaper than Fable 5, outperforms it on several benchmarks, and engages its safety classifiers about 85% less often — deliberately, because Anthropic chose not to give it cutting-edge cybersecurity capability, so it carries a lower risk profile and needs fewer guardrails. It also ships a beta feature, Automatic Fallbacks, that reroutes a request which trips a safety classifier to a less powerful model instead of returning an error. (Pricing and exact figures come from secondary coverage; treat the numbers as directional.)

Read those two facts together and a line has quietly been crossed. Restriction level is now a purchasable product axis — sitting alongside price and capability as a thing you spec, not a fixed property of "the model." The Claude 5 lineup now tiers partly by permission: a broadly-sold tier with classifier routing on risky queries, a cheaper tier with far less classifier engagement and different data-retention terms, and a gated tier behind a consortium with mandatory retention. Capability, retention policy, and refusal behavior now vary independently. Any enterprise whose model policy reads "use the most capable tier" just discovered that sentence no longer specifies a single thing.

Three axes where there used to be one

The old procurement question was one-dimensional: how capable, at what price. The new lineup forces three questions that don't move together.

Capability — the benchmark axis everyone already tracks. Retention — whether prompts and outputs are held, and for how long, which is a compliance and data-residency question entirely separate from how smart the model is. And restriction — how often the model refuses or routes around a request, which is now tunable and priced. A team that specs only the first axis and inherits the other two by accident has made two consequential decisions without noticing: it may have picked a retention posture its regulator cares about, and a refusal-behavior profile its risk team never reviewed.

The restriction axis also isn't a simple dial from "safe" to "permissive." Opus 5's guardrails reportedly draw lines inside a single task family — blocking, say, scanning compiled binaries for vulnerabilities while permitting source-code vulnerability search. So "less restrictive" doesn't mean "unrestricted"; it means a different shape of restriction that your security use cases have to be checked against specifically. You cannot infer the boundary from the marketing adjective.

Automatic Fallbacks makes refusals invisible

Here is the part that changes audit, and it's easy to miss. Historically a safety refusal was legible: you asked, the model declined, you got an error, everyone knew a boundary was hit. Automatic Fallbacks dissolves that. A blocked request no longer surfaces as a block — it silently gets answered by a weaker model, and the caller receives a functional response. Convenient. Also a provenance problem.

Because the audit question just shifted. It used to be "what can the model do?" It is now "which model actually answered this request?" When a compliance reviewer pulls a transcript, "we used Opus 5" may not be true for the requests that tripped a classifier and fell back — those were answered by something else, quite possibly a less capable model, on the requests most likely to be sensitive. If the fallback isn't disclosed in the API response — and I couldn't confirm whether it is — then your logs say Opus 5 for answers Opus 5 didn't produce.

rendering diagram…

What procurement and audit have to do now

At work, this reframes the model-selection conversation I'm in constantly. "Use the best model" is no longer a policy; it's an underspecified wish. The policy now needs three named choices per workload — capability tier, retention posture, restriction profile — each justified against that workload's actual requirements, because a coding-agent's needs on all three differ from a customer-facing assistant's. And it needs a rule on fallbacks: for regulated or sensitive workloads, I'd default to fallbacks off, precisely because a legible refusal you can handle is safer than a silent downgrade you can't see. An error is a known state. A quietly-rerouted answer on a flagged request is an unknown one, on exactly the requests where you least want unknowns.

The audit requirement follows directly: the answering model must be recorded per request, not assumed from the configured default. If your logging captures "model: opus-5" from config rather than from the response's actual provenance, it will confidently lie about every fallback. Capture what answered, not what you asked for.

Steal this checklist for the new lineup: spec every workload on three axes (capability, retention, restriction), not one; decide fallbacks on/off per workload and default them off where refusals are compliance-relevant; and verify your logs record the responding model's identity, then test it by sending a request you expect to trip a classifier and confirming the log names what actually answered. Restriction became a product; treat it like one you have to audit.

"Less restrictive" is now a line item, and a silent fallback is an unlogged model swap — spec restriction like retention, and record which model actually answered, not which one you asked for.