Claude Fable 5's 30-Day Retention: ZDR, HIPAA, COPPA

If your organization runs Claude under a zero-data-retention (ZDR) agreement, your first request to claude-fable-5 didn't return a completion. It returned 400 invalid_request_error. That's not an outage — it's policy. Fable 5 is the first generally available Claude model that cannot be used without 30-day data retention, and the requirement follows the model onto every platform: the Claude API, AWS Bedrock, Google Vertex AI, and Microsoft Foundry each gate it behind an explicit retention opt-in.

For teams that treated "we don't retain your data" as a settled property of their LLM stack, this is an architectural event. This post covers what the policy says, why the window exists, how each cloud implements it, and what it changes for consumer products and sensitive-data industries.

Policy details were checked against Anthropic's, AWS's, Google's, and Microsoft's published documentation on 2026-06-12. Policies change; verify against the linked primary sources and your own contracts. This is an engineering overview, not legal advice.

What the policy actually says

Anthropic designates Claude Fable 5 and Claude Mythos 5 as Covered Models. Per the API data retention docs and the Mythos-class retention practices article (effective 2026-06-09):

Prompts and completions are retained for 30 days, then automatically deleted — unless flagged for an active safety investigation or required by law.
There is no opt-out. Retention is a condition of using the model. A request from an organization whose retention configuration doesn't meet the requirement returns 400 invalid_request_error.
Access is narrow by design. Automated safety systems screen the data; only a small group of approved personnel can review flagged conversations, they cannot export, copy, or download it, and every access lands in tamper-proof logs.
Existing ZDR agreements do not carry over to Covered Model traffic — including through cloud platforms.

Consumer plans (Claude Free/Pro/Max) are unaffected — they already operate under their own retention terms. This policy targets the commercial API surface, exactly where "we never retain" promises tend to live.

Why a 30-day window exists

The rationale in the Covered Models article is specific: these models have substantially advanced capabilities in software engineering, agentic workflows, and cybersecurity, and "some forms of misuse only become detectable across many requests." The cited examples — best-of-N jailbreaking, state-sponsored espionage — are attack patterns where each prompt looks benign and only the sequence is diagnostic. You can't detect a sequence you've deleted.

Two things the window is not:

Not training data. Anthropic states retained data is never used for training without express permission. The purpose is abuse detection, full stop.
Not new in kind — new in enforceability. A ~30-day abuse-monitoring window has been the industry default for years: OpenAI keeps API abuse logs up to 30 days (ZDR by approval); Azure OpenAI stores prompts up to 30 days unless approved for modified abuse monitoring. What changed is that the window became non-negotiable for one model class — previously every provider offered a zero-retention escape hatch.

One pre-existing caveat that surprises people: even under ZDR, Anthropic retains safety classifier results, and content flagged for Usage Policy violations can be kept up to 2 years. Zero data retention has never meant zero data — it means zero retention of unflagged content in the normal path.

Same requirement, three clouds, three mechanisms

The retention applies wherever the model runs, but each platform wires the opt-in differently — and the differences decide who processes your data and where your controls live.

Platform	Opt-in mechanism	Scope	Without opt-in
Claude API	30-day retention in Privacy controls	Organization or workspace	`400 invalid_request_error`
AWS Bedrock	`data_retention_mode: provider_data_share`	Account or project	Model listed `unavailable`; requests blocked
Google Vertex AI	Anthropic data sharing + Model Garden terms	Project	Requests blocked until enabled
Microsoft Foundry	Anthropic's terms accepted at deployment	Subscription/deployment	Not covered by Azure's ZDR program at all

AWS Bedrock is the most explicit. Data retention is a configurable mode (default / provider_data_share / none), resolved project → account → model default. Fable 5 declares allowed_modes: ["provider_data_share"]: prompts and completions are shared with Anthropic and retained up to 30 days. Under any other mode:

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Nothing changed for pre-Fable-5 models, and an SCP on the bedrock:DataRetentionMode condition key can enforce your posture org-wide — nobody quietly flips the account to try the new model. Note: with cross-region inference, the retained copy lives in the destination region, which matters if you carry residency commitments.

Google Vertex AI gates the model behind a project-level Anthropic data-sharing setting (setPublisherModelConfig with dataSharingEnabledProvider: "anthropic") plus terms acceptance in Model Garden, per Google's Fable 5 documentation. General data handling follows Vertex AI's data-governance policy; for residency-sensitive workloads, Vertex's regional and multi-region endpoints control where inference runs — which now includes where the retained copy lives.

Microsoft Foundry is structurally different. Microsoft's data and privacy documentation is explicit that Claude models are third-party marketplace services: you accept Anthropic's terms at deployment, and Anthropic — not Microsoft — is the data processor. Azure OpenAI's ZDR and modified-abuse-monitoring programs don't extend to Claude deployments. Organizations with ZDR postures elsewhere typically isolate Covered Model use in a dedicated subscription, making the retention boundary structural rather than procedural.

The pattern across all three: retention class became a first-class, machine-readable model attribute — a mode, a flag, a terms gate — rather than a paragraph in a contract. Your infrastructure can now enforce your data posture, and it should.

What it means for enterprise deployments

With no ZDR agreement, nothing changes mechanically — you were already in a 30-day-style posture, possibly without realizing it. The work is making it explicit in your vendor documentation.

With a ZDR agreement, you have a three-way choice:

Skip Covered Models. ZDR stays uniform; you give up the model. Viable if your workloads don't need it — see our measured Fable 5 evaluation for what it costs and where it differs.
Split by workspace or project. Every platform supports a scoped opt-in: a designated Claude API workspace (Console → Settings → Workspaces → Privacy controls), a Bedrock project with provider_data_share, a separate Vertex project or Azure subscription. Route only retention-tolerant workloads there.
Accept retention org-wide. Simplest to operate, but it silently downgrades the guarantee for every workload — including the ones whose sensitivity justified ZDR. That's a decision for your data-protection owner, not a config change.

Regardless of provider: your own logging is a second retention surface. If your gateway or observability stack logs full prompts, you're running a longer window than your provider, under your own roof. Provider guarantees are only as meaningful as the layer in front of them — the same audit logic we applied to cache claims applies here.

What it means for consumer-facing products

If you serve consumers and route their content through a Covered Model, the change propagates into your own legal surface — ZDR agreement or not. Three concrete consequences:

1. Your privacy notice probably needs an update. Most regimes require disclosing retention, not just collection: GDPR Article 13(2)(a) requires the storage period (or criteria) at collection time; California's CPRA requires the notice at collection to state retention per category of personal information. If your notice says — or implies — that conversation data isn't retained anywhere, a processor holding a 30-day copy makes it wrong. Update the notice, the records of processing, and the DPA inventory.

2. You cannot offer users an opt-out you don't have. The retention has no exception mechanism, so there is no toggle you can build that exempts a user's prompts while still using that model. The lever you actually hold is routing: a consent-aware gateway sends users who decline data sharing to ZDR-eligible models and everyone else to the Covered Model — a legal constraint turned into an ordinary routing rule. Far better than a preference checkbox that does nothing.

3. Deletion requests need accurate plumbing. Erasure obligations (GDPR Art. 17, CPRA deletion, and their equivalents) extend to processors. A bounded window that auto-deletes within 30 days is generally a defensible processor posture — but your DSAR playbook should say that, not promise immediate downstream deletion you can't execute.

The global dimension compounds this: the same disclosure-and-processor logic appears in the UK GDPR, Brazil's LGPD, and the spreading family of US state privacy laws. For users in China, PIPL adds two sharper edges — providing personal information to another processor generally requires separate consent, and routing Chinese users' content to an overseas LLM endpoint is a cross-border transfer needing a recognized mechanism (security assessment, standard contract, or certification). A model upgrade that changes who retains what, where, for how long is exactly the change these frameworks expect you to re-paper.

Sensitive-data industries: where 30 days bites hardest

For most products the provider's window is a documentation problem. For industries whose data is itself regulated, it's an architecture problem: the retained copy is regulated data at rest at a vendor, and sector rules govern exactly that.

Healthcare (HIPAA)

HIPAA doesn't require zero retention — it requires that any vendor holding protected health information does so under a Business Associate Agreement (BAA) with appropriate safeguards. The 30-day copy of your prompts is PHI at rest at a business associate; the question is whether your BAA covers it. The two major API vendors structure this differently, and the difference now matters: Anthropic's HIPAA-ready API access explicitly doesn't require ZDR — it's built on retention-with-safeguards (encryption, access controls, audit logging, enforced feature restrictions). OpenAI's API BAA covers endpoints eligible for zero data retention — and a BAA scoped to ZDR endpoints structurally cannot cover a model that mandates retention.

A model's retention class is now a BAA-eligibility question. Confirm in writing that your BAA covers the specific model before routing PHI to it — and remember the chain shifts on clouds: on Bedrock the platform is your business associate; on Foundry, Anthropic processes the data directly. One sharp edge: PHI must never appear in JSON schema definitions for structured outputs — cached schemas don't get the same protections as message content.

Children's products (COPPA)

The timing is awkward: the FTC's amended COPPA Rule took effect June 23, 2025, with compliance on most provisions due April 22, 2026 — the first model with mandatory provider-side retention arrived just as operators finished implementing the new retention obligations. Two of those interact directly with the 30-day window: a written, public data retention policy is now mandatory (§312.10) — what children's data is collected, why, and when it's deleted — and indefinite retention is prohibited, with retention limited to what's reasonably necessary for the collected purpose.

A bounded 30-day window with automatic deletion is the compatible shape — but the provider retains for its trust-and-safety purpose, not the purpose you collected the child's data for, and your notice must describe the processor relationship accurately. For child-directed products that adopted ZDR specifically to minimize the data trail, the routing answer applies with higher stakes: children's traffic stays on ZDR-eligible models, or the Covered Model window goes into your §312.10 policy first.

The same pattern, other sectors

Once you see the structure — regulated data, retained copy at a vendor, sector rule governing retention — it recurs:

Biometrics (Illinois BIPA): operators need a written, publicly available retention schedule and destruction guidelines for biometric data. A provider's 30-day copy of prompts containing biometric identifiers belongs in that schedule.
Payments (PCI DSS / GLBA): PCI DSS prohibits storing sensitive authentication data after authorization — anywhere. Card data pasted into a prompt becomes card data retained at a provider for 30 days. The clean answer is upstream redaction, not downstream paperwork.
Education (FERPA): vendors handling student records under the school-official exception must remain under the school's direct control. A safety-retention copy the school cannot access or delete early sits uneasily with that standard — a question for counsel before EdTech traffic hits a Covered Model.
Financial services — the inversion (SEC/FINRA): broker-dealers must retain business communications under books-and-records rules. For them the provider's window isn't the problem; capturing their own compliant copy is. Same retention question, opposite sign.

The common thread: sector rules regulate retention in both directions, and a provider-side window you don't control must be mapped into whichever direction your sector points.

A decision checklist

✅ Inventory which models your traffic actually touches. Retention class is now a per-model attribute, not a per-provider one.
✅ If you have ZDR: decide deliberately — skip Covered Models, split by workspace/project/subscription, or accept retention org-wide. Don't let it happen implicitly.
✅ Enforce the posture in infrastructure — Bedrock SCPs, workspace privacy controls, separate cloud projects — not in a wiki page.
✅ B2C: update privacy notices and DSAR playbooks; route non-consenting users to ZDR-eligible models instead of building opt-outs that can't work.
✅ Regulated data: confirm coverage per model, in writing — BAA for PHI, §312.10 policy for children's data, retention schedules for biometrics — before routing that data to a retention-required model.
✅ Audit your own logging. A provider's 30-day window is irrelevant if your gateway logs prompts indefinitely.

Bottom line

The 30-day window attached to Fable 5 is not a data grab — it's bounded, purpose-limited abuse monitoring, consistent with what most of the industry already does by default, made mandatory for one model class because cross-request misuse detection doesn't work on deleted data. For most teams the engineering impact is zero and the governance impact is a paragraph in a vendor review.

But for organizations whose compliance position assumed zero retention — ZDR-scoped BAAs, privacy notices that say nothing persists, children's products built on data minimization — Fable 5 is the moment that assumption stopped being uniform across models. The fix isn't avoiding the model. It's making retention class an explicit, per-model input to routing decisions, the same way you already treat price and context window.

FAQ

Can I use Claude Fable 5 under a zero-data-retention agreement?
No. Fable 5 and Mythos 5 are Covered Models requiring 30-day retention; ZDR organizations get a 400 invalid_request_error unless they enable 30-day retention for a workspace and route Fable 5 traffic through it.

Does going through AWS Bedrock, Vertex AI, or Microsoft Foundry avoid the requirement?
No. Each platform gates the model behind its own retention opt-in: provider_data_share on Bedrock, Anthropic data sharing plus Model Garden terms on Vertex, Anthropic's terms at deployment on Foundry (where Anthropic, not Microsoft, is the data processor). Existing ZDR arrangements don't carry over on any of them.

Can my end users opt out of the retention?
No — there is no opt-out mechanism. The lever you hold is routing: send users who decline data sharing to ZDR-eligible models. Don't ship a preference toggle that doesn't change anything.

Is the retained data used to train models?
Anthropic states retained data is never used for training without express permission. The purpose is trust-and-safety review: automated screening, with flagged conversations reviewable only by approved personnel who cannot export the data, under tamper-proof access logs.

Does the 30-day retention change how prompt caching works?
No. Cache entries follow their own short TTLs (5 minutes or 1 hour) and the caching contract on Fable 5 is unchanged — see our measured evaluation. The 30-day window is a separate, parallel retention for safety review.