Opus 5 and Zero Data Retention, The Compliance Gap That Forces a Migration

Here is the fact that has not made it into the Opus 5 launch coverage. Claude Opus 5 can run under a Zero Data Retention arrangement, and Claude Fable 5 and Claude Mythos 5 cannot. Both are designated Covered Models requiring 30-day data retention, and ZDR is not available for either.

For a regulated organisation, that is not a preference — it is a constraint that decides which model you are allowed to call. And because Opus 5 also happens to be cheaper and better on the published boards, the compliance argument and the capability argument point the same way for the first time in a while.

This walks through what ZDR actually covers, where it silently does not apply, how HIPAA readiness differs, and the configuration traps that catch teams out. Companion reading, the Opus 5 system card explained and the full price sheet.

The retention landscape

Log scale. Zero is a genuine zero — under ZDR, prompts and responses are not stored at rest after the response is returned.

The last row matters and is easy to miss. Even with ZDR or HIPAA in place, content flagged by automated trust and safety systems may be retained for up to two years. ZDR is a strong commitment about normal operation, not an absolute guarantee about every byte in every circumstance.

The Covered Models rule, concretely

Fable 5 and Mythos 5 require 30-day retention wherever they are offered. If your organisation's retention configuration does not meet that requirement, the API refuses the call outright with a 400 invalid_request_error telling you that data retention must be enabled to access the model.

That produces a genuinely awkward position for a ZDR customer, the previous frontier model is unusable, and the workaround is to deliberately weaken your own posture. Anthropic supports it — an organisation with ZDR can enable 30-day retention on a single workspace so Fable 5 and Mythos 5 work there while every other workspace stays at zero retention.

If you carved out a retention-enabled workspace purely to reach Fable 5, Opus 5 is a reason to revisit that. You may be able to collapse the exception entirely — better capability, half the price, and one fewer deviation to explain in an audit.

What ZDR covers, and the gaps that catch people

ZDR applies to the Messages and Token Counting APIs for eligible features, to Claude Code when used with API keys from a Commercial organisation or through Claude Enterprise with ZDR enabled, and to Claude Platform on AWS on request.

The exclusions are where teams get surprised

The Console exclusion is the practical one. An organisation can have a spotless ZDR arrangement on its production API path while engineers paste customer data into the Workbench to test a prompt. That is not a technical failure, it is a policy and training gap, and it is the most common real-world hole.

Note also that under ZDR a non-eligible feature is not blocked. The request succeeds and that feature's own retention policy applies. Using the Files API under a ZDR arrangement is a choice to step outside it for that data, made silently. HIPAA readiness behaves differently — it returns a 400 rather than letting you wander out of scope.

ZDR versus HIPAA readiness

These solve different problems and you generally want one, not both.

Two details deserve emphasis. HIPAA readiness is permanent — once an admin accepts the BAA it cannot be disabled, and it is enforced organisation-wide, so you need separate organisations for HIPAA and non-HIPAA workloads. And Claude Code is not covered under HIPAA readiness at all, which is a hard stop if your plan was to let engineers point a coding agent at a repository containing PHI.

The JSON schema trap

This one is subtle enough that it deserves its own section. When you use structured outputs or strict tool use, the API compiles your JSON schemas into grammars that are cached separately from message content — for up to 24 hours since last use.

Those cached schemas do not receive the same protections as prompts and responses. Anthropic's guidance is explicit, do not put PHI in schema property names, enum values, const values, or pattern regular expressions.

It is easy to violate accidentally. An enum of real patient categories, a regex encoding a real account-number format, a property named after a specific customer — all plausible in ordinary code, all in the wrong place. Patient-specific information belongs in message content, where the safeguards apply.

Claude Code specifics

Coding agents touch source code, credentials in config files, and occasionally production data pulled in during debugging. The retention question is not academic.

• ZDR applies when Claude Code runs on API keys from a Commercial organisation, or through Claude Enterprise with ZDR enabled.
• ZDR does not apply on consumer Free, Pro or Max accounts — including engineers using personal subscriptions for work.
• Metrics logging is exempt. If enabled, productivity data such as usage statistics may be retained even under ZDR.
• HIPAA does not cover Claude Code at all.

The consumer-account point is the one worth auditing this week. An organisation can hold a ZDR arrangement and still have half its engineers running Claude Code on personal Max subscriptions, entirely outside it. That is an access-management question, not a vendor question, and no contract clause will fix it for you.

Which features stay inside ZDR

It helps to know what you can build with while keeping the arrangement intact. The core inference path is broadly eligible.

Two features sit in a middle category Anthropic labels "yes, qualified", your prompts and outputs are not stored, but a bounded technical artefact is. Cache diagnostics retains a fingerprint of hashes and token estimates, structured outputs caches the compiled JSON schema for up to 24 hours. Both are documented and narrow, but if your threat model is strict, know they exist.

Encouragingly for coding teams, almost everything you need for a serious agent — 1M context, thinking, effort control, prompt caching, computer use, bash and text editor tools, memory — is fully eligible. The features that fall outside are the stateful ones, and that is a coherent line rather than an arbitrary one.

Questions to put to your account team

If you are procuring or renewing, these are the ones that change architecture rather than paperwork.

1. Is ZDR enabled on every organisation we use, including ones created after the original agreement? It does not extend automatically.
2. Which of our workspaces have 30-day retention overrides, and were they created solely to reach a Covered Model?
3. Are any engineers using Claude Code on consumer accounts? That usage sits outside the arrangement entirely.
4. Is Claude Code metrics logging on? Productivity data is exempt from ZDR.
5. Do we need HIPAA readiness instead? It is permanent and org-wide, and excludes Claude Code.
6. Where is inference running? Data residency is a separate control from retention.
7. On Bedrock or Google Cloud, who is the processor? Not Anthropic — those platforms' policies govern.

That last point catches larger organisations often. The ZDR and HIPAA arrangements described here apply where Anthropic is the data processor. Run the same model through Amazon Bedrock or Google Cloud's Agent Platform and the cloud provider is the processor, with its own equivalent controls. Your Anthropic contract does not follow the model onto someone else's infrastructure.

A practical compliance checklist

1. Confirm your arrangement. ZDR is per organisation and does not extend to new organisations under the same account.
2. Audit which models you call. Fable 5 and Mythos 5 force 30-day retention, Opus 5 does not.
3. Collapse retention exceptions created solely to reach a Covered Model, now that Opus 5 exists.
4. Ban production data from Console and Workbench. Neither is ZDR-eligible.
5. Inventory stateful features in use — Files API, Batch, code execution, Managed Agents all sit outside ZDR.
6. Check Claude Code account provenance. Personal subscriptions are outside your arrangement.
7. Scrub JSON schemas of anything sensitive.
8. Write down the flagged-content exception. Up to 2 years, regardless of arrangement — your risk register should say so.

Common questions

Is Claude Opus 5 available under Zero Data Retention?

Yes, on ZDR-eligible features. Unlike Fable 5 and Mythos 5, it is not a Covered Model and does not force 30-day retention.

Why can I not use Fable 5 with ZDR?

Fable 5 and Mythos 5 are designated Covered Models requiring 30-day data retention. Calls from an organisation without that retention configured return a 400 error.

Does Anthropic train on API data?

Retained data is never used for model training without express permission. Standard API inputs and outputs are retained for 7 days.

Is Claude Code covered by ZDR?

Yes with Commercial API keys or Claude Enterprise with ZDR enabled. No on consumer Free, Pro or Max accounts, which is the most common real-world gap. Metrics logging data is exempt even under ZDR.

Do I need both ZDR and HIPAA readiness?

No. HIPAA readiness is the alternative for organisations handling PHI, and it applies broader safeguards rather than immediate deletion.

Does ZDR mean nothing is ever stored?

No. Content flagged by automated trust and safety systems may be retained up to 2 years, and legal holds apply regardless of arrangement.

Does ZDR apply on Bedrock or Google Cloud?

No. Those arrangements cover the Claude API, where Anthropic is the data processor. On Amazon Bedrock and Google Cloud's Agent Platform the cloud provider is the processor, and their own retention and compliance controls apply instead.

Can one organisation run both HIPAA and non-HIPAA workloads?

No. HIPAA readiness is enforced organisation-wide and blocks non-eligible features automatically, so you need a separate organisation for general-purpose work.

Sources and further reading

• Claude Platform docs. API and data retention
• Claude Code docs, data usage
• Anthropic Trust Center
• The Opus 5 system card explained
• Claude Opus 5 scorecard

A closing thought on why this matters more each release. Compliance posture used to be decided once, at procurement, and then left alone. With a model cadence measured in weeks, the model your engineers actually call can drift away from the one your arrangement covers without anybody filing a change request. The teams handling this well have a short, boring document that lists which models are approved under which arrangement, and they update it on launch day rather than at audit time. Opus 5 is a good occasion to write yours, because for once the compliant choice is also the cheaper and stronger one.