You Requested Claude Opus 5. Check Which Model Answered.

An Opus 5 request can produce a response from Opus 4.8 on supported surfaces after a safety-classifier decline. Regulated teams should qualify and monitor the model that served the work, not rely on the model named in configuration.*

Anthropic released Claude Opus 5 on 24 July 2026 with a control that changes what "we used Opus 5" can mean. In Claude.ai, Claude Code and Claude Cowork, requests flagged by its safety classifiers fall back to Opus 4.8 by default. Direct Claude API customers can opt into server-side fallback (Anthropic).

The model named in the request identifies what the application requested. It does not, by itself, prove which model produced the returned answer. For supported API fallback, Anthropic exposes the serving model and fallback trail in the response, but your application has to retain and use that evidence (Anthropic documentation).

This is also a different problem from model retirement. A retirement date or a surface lifecycle change tells you when a model stops being available, and you can plan around the calendar. Fallback changes which model answered while every dashboard still shows the service as available. The lifecycle risk is scheduled; the attribution risk is silent.

For Australian financial-services teams, this is a served-model attribution issue. If a secure-code review, control-testing draft or research workflow was evaluated as Opus 5, a response served by Opus 4.8 belongs in a separate evidence cohort until a human owner confirms that the fallback model is approved for that task.

When can another model answer?

Start by separating product behaviour from API configuration. Anthropic says its own Claude.ai, Claude Code and Cowork surfaces use Opus 4.8 by default when Opus 5 safety classifiers flag a request. In the direct Claude API, automatic server-side fallback is optional and currently in beta. A developer can ask Anthropic to use a recommended default fallback or provide their own list of up to three permitted fallback models (Anthropic documentation).

Fallback is not generic resilience for every failed request. Anthropic's documentation says only a safety-classifier decline triggers automatic fallback. Rate limits, overloads and server errors are returned without it. If your runbook says "fallback handles outages", it describes a different mechanism.

Surface also matters. Anthropic currently documents server-side fallback, in beta, on the Claude API, including the Claude Platform on AWS. It is not supported in Message Batches and is not available through Amazon Bedrock, Google Cloud or Microsoft Foundry. Anthropic describes client-side SDK middleware as the alternative across platforms. Do not copy a direct-API test result into a hosted-platform approval without checking that platform's implementation (Anthropic documentation).

For supported API fallback, the response contains the evidence needed to distinguish request from service:

Streaming needs an extra check. If a fallback happens after output begins, the initial message event can still name the requested model. Anthropic directs developers to the fallback block and final usage iterations for the full trail. Reading only the first streaming event can preserve the wrong attribution (Anthropic documentation).

Opus 5 migration also changes more than a model string. Anthropic's migration guide says thinking is on by default, documents unavailable features including web fetch and Priority Tier, and tells developers to handle the refusal stop reason (Anthropic migration guide). Those settings belong in the qualification record because they can change workflow behaviour even when no fallback occurs.

Why does this contaminate an evaluation?

An evaluation grouped only by requested model can mix outputs from different serving models. The average score may still look tidy, but it no longer answers the question the approval was meant to test: how did the approved model perform on this workflow?

Use served-model cohorting. Keep every completed response in a cohort defined by the model that actually served it. Record the requested model as a separate field. Then calculate a fallback contamination rate:

completed responses where requested model differs from served model ÷ all completed responses for the workflow

The number is not a performance score. It is a warning that the headline evaluation includes a mixed population. Report the overall result, the requested-equals-served cohort, each fallback cohort and unresolved refusals separately.

Fictional worked example: [USECASEID] is an internal secure-code-review assistant tested only on synthetic code. The team sends 40 test cases requesting Opus 5. Thirty-seven completed responses are served by Opus 5 and three are served by Opus 4.8 after documented fallback. The contamination rate is 3 divided by 40, or 7.5 per cent.

The evaluator does not discard the three responses. It places them in an Opus 4.8 cohort, reports their task results separately and checks whether that model is approved for [USECASEID]. [HUMANMODELRISKOWNER] then decides whether the test supports release, requires a restriction or must be repeated with different fallback configuration.

This technique also improves incident reconstruction. When a problematic output is reported, the team can identify what was requested, what answered, which attempts occurred and what configuration was active. It does not have to infer the model from a user-interface label or invoice. The same discipline pays off when access to a model is gated or withdrawn: the record of what actually served the work is what survives the change.

For an APRA-regulated entity, that evidence can support existing technology, change and service-provider risk controls. CPS 230 requires operational-risk management and assessment of the impact of new products, services, geographies and technologies on the entity's operational risk profile; whether a particular AI arrangement is material remains an organisation-specific assessment (APRA CPS 230). The fallback record is an assurance input, not a new model approval made by the technology itself.

What should the evidence record capture?

Keep a served-model evidence record for each regulated or high-impact workflow. It can be compact, but it must join the request, response, evaluation and human decision.

The minimum fields are:

1. Use-case ID, response ID, timestamp and environment.
2. Requested model, API surface, fallback setting and configuration version.
3. Top-level served model and final stop reason.
4. Fallback from-model and to-model, where present.
5. Every model and attempt type in the usage iterations.
6. Test-set or work-item ID, without unnecessary customer or employee content.
7. Evaluation outcome, exception status and approved-model register result.
8. Human reviewer, decision, rationale and follow-up action.

Do not turn this into a second store of prompt content. Use stable identifiers, controlled hashes or references to protected source records where appropriate. Privacy, security and records specialists should decide what must be retained and for how long.

Use this prompt to extract a proposed evidence record from redacted API material. A platform engineer must compare every field with the raw request and final response before it is saved.

Act as an evidence-extraction assistant, not an approval decision-maker.

Review the redacted Claude API request and final response. Return:
- response ID
- requested model
- top-level served model
- fallback observed: yes, no or unclear
- each from-model and to-model
- every usage iteration model and type
- final stop reason
- configuration and beta version
- missing evidence
- claims that cannot be supported

Use the sent request for the requested model. Use the response's top-level model for the served model. Do not infer a refusal category if the evidence does not expose one.

REQUEST:
[PASTE_REDACTED_REQUEST]

FINAL RESPONSE:
[PASTE_REDACTED_RESPONSE]

Use this prompt to separate an evaluation into served-model cohorts. A human model-risk owner must review the source results and make the qualification decision.

Review [EVALUATION_TABLE] for [USE_CASE_ID].

Group completed responses by requested model and served model. Calculate:
1. total completed responses
2. requested-equals-served count
3. each fallback cohort count
4. fallback contamination rate
5. task results for each served-model cohort
6. refusals and records with missing served-model attribution

Flag any result that combines served models, any fallback model absent from [APPROVED_MODEL_REGISTER], and any missing served-model attribution, final stop reason or iteration trail.

Do not approve the model or workflow. Produce questions for [HUMAN_MODEL_RISK_OWNER].

The evidence record should say "safety-classifier fallback observed" unless the retained fields support a more specific category. A neat narrative is not a substitute for the actual response fields.

Do this Monday

1. Find every Opus 5 workflow. Record whether it runs in an Anthropic product, the direct API, Message Batches or another cloud platform. Do not assume the fallback behaviour is identical.
2. Inspect the final response parser. Confirm that it retains the top-level served model, fallback block, final stop reason and complete usage iterations. Test streaming paths as well as ordinary responses.
3. Define approved fallback models. For each use case, record whether a fallback model is permitted, prohibited or awaiting evaluation. Make the human model-risk owner explicit.
4. Re-cut the test results. Group existing Opus 5 evaluations by served model. Calculate the contamination rate and reissue any conclusion that relied on a mixed cohort.
5. Add a production alert. Flag an unapproved served model, missing served-model attribution fields or an unexpected change in fallback rate for human investigation. Do not let the alert decide whether work can be used.

If the team uses Message Batches or a cloud-hosted surface, document its actual refusal and retry design. A generic statement that "Anthropic handles fallback" is not a control.

Bottom line

The model in configuration is the requested model. The model in the final response is the one that served the work. Keep both, preserve the fallback trail and evaluate each served-model cohort separately. A human owner should decide whether a fallback output is within the approved use case before anyone relies on it.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Anthropic, "Introducing Claude Opus 5": https://www.anthropic.com/news/claude-opus-5
2. Anthropic, "Refusals and fallback": https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback
3. Anthropic, "Migrating to Claude Opus 5": https://platform.claude.com/docs/en/about-claude/models/migration-guide
4. APRA, "Prudential Standard CPS 230 Operational Risk Management": https://www.apra.gov.au/standards/cps-230