Anthropic's most capable model tier just arrived on Amazon Bedrock with a condition attached: to call Claude Fable 5 or Claude Mythos 5, you have to let your prompts and completions leave AWS's security boundary. In the June 9, 2026 launch announcement, AWS confirmed that both Mythos-class models require a new provider_data_share retention mode, and there is no way to use them without it. For creators building production apps, agents, and games on top of Fable 5, that is not a footnote. It is a data-governance decision you have to make before you write a single line of integration code.

What Happened

On June 9, AWS made Claude Fable 5 generally available on Bedrock in the US East (N. Virginia) and Europe (Stockholm) regions, with more regions promised. Fable 5 and its sibling, Claude Mythos 5, are Anthropic's Mythos-class models, the tier built for long-horizon autonomy and complex app and game generation. The capability story is the one that topped Hacker News. The story that kept it there was buried in the data-retention details.

Unlike Claude Opus 4.8 and the rest of the standard Bedrock lineup, which default to zero data retention, the Mythos-class models will not run until a customer explicitly switches their account into provider_data_share mode through the Bedrock Data Retention API. There is no console toggle for it at launch. Once that flag is set, as the AWS post states plainly, "your data will leave AWS's data and security boundary."

The Data Boundary Problem

For most teams, the entire reason to run Claude on Bedrock instead of calling Anthropic directly is the AWS boundary. Inference stays inside your AWS account's security and compliance perimeter, covered by the agreements, regions, and controls you already have in place. The Mythos-class data-retention policy breaks that assumption for these two models specifically.

With provider_data_share enabled, Anthropic retains inputs and outputs for up to 30 days and subjects them to human review. That means the prompt your app sends, which may carry user content, client material, or proprietary instructions, plus the model's response, are copied out of AWS and held by a third party for a month. For a hobby project that is a shrug. For an agency handling client footage, a studio with unreleased IP in its prompts, or a regulated team in healthcare, legal, or finance, it is a hard stop that has to clear procurement and compliance first.

Diagram of data leaving the AWS security boundary to Anthropic under provider_data_share
With provider_data_share enabled, Mythos-class prompts and completions leave the AWS boundary for 30-day retention and human review.

Why Anthropic Requires It

The requirement is not a revenue play, it is a safety control. Mythos-class models are the most autonomous Anthropic ships, capable of building and modifying entire applications from a description. Anthropic's position, echoed in Dario Amodei's policy on the AI exponential, is that more capable models need more visibility into how they are used. The AWS announcement frames the retention this way: holding data temporarily "allows Anthropic to detect patterns of misuse that are not visible from a single exchange."

That logic is coherent. A single prompt rarely reveals an attack, but a sequence across many calls can. The catch is that misuse detection at the model-provider level only works if the provider can see the traffic, which is exactly the visibility most enterprise Bedrock customers chose Bedrock to avoid. The same safeguards that triggered criticism from security researchers over Fable's guardrails are the reason the data-sharing mandate exists.

It also sets a precedent worth watching. The AWS announcement frames provider_data_share as the requirement for "Mythos and future models," which signals that Anthropic's most capable tiers may carry this condition going forward rather than as a one-time exception. If that holds, the choice creators make today between a boundary-preserving model and a more capable one that shares data becomes a recurring tradeoff, not a single decision tied to Fable 5.

Retention Modes Compared

Here is how the Mythos-class requirement stacks up against the default Bedrock behavior that applies to models like Opus 4.8. The Mythos model card spells out the same constraints.

DimensionStandard Bedrock models (e.g. Opus 4.8)Mythos-class (Fable 5, Mythos 5)
Data retentionNone by defaultRequired (provider_data_share)
Data leaves AWS boundaryNoYes
Retention periodNot retainedUp to 30 days
Human reviewNoYes
Opt-out and still use modelN/ANot possible
How to enableDefaultData Retention API (no console UI)
Launch regionsBroadN. Virginia, Stockholm
Comparison chart of standard Bedrock retention versus Mythos-class provider data share mode
Standard Bedrock models retain nothing by default, while Mythos-class models mandate 30-day retention and human review.

What This Means for Your Workflow

If you are deciding whether to build on Fable 5, the data flag changes the calculus by workload, not by company. The same studio might happily run Fable 5 on a marketing microsite while keeping it far away from an unreleased game build. Treat the decision as per-project, and sort your work into three buckets: content you would not mind a reviewer seeing, content under client or NDA confidentiality, and content under regulatory control.

For the first bucket, provider_data_share is a non-issue and Fable 5's app-building power is a clear win. For the second and third, you either keep Mythos-class models out of the pipeline or you route only sanitized, non-sensitive prompts to them. Many teams will end up with a split stack: Fable 5 for the generative heavy lifting where data sensitivity is low, and Opus 4.8 for everything that has to stay inside the AWS boundary.

Three workflow buckets for routing prompts based on data sensitivity
Sort each project into reviewable, confidential, or regulated, then route Mythos-class calls only to the first.

What to Do Next

Before you ship anything on Fable 5, read the data-retention terms in full, confirm whether your contracts or compliance regime permit data leaving the AWS boundary, and set provider_data_share through the API only for the workloads that pass that check. If you already run Claude on Bedrock, note that this requirement is specific to the Mythos tier and does not change retention for your existing Opus or Sonnet calls, including workloads like other Bedrock-hosted coding models.

Frequently asked questions

Can I use Claude Fable 5 on Bedrock without sharing data?

No. The provider_data_share retention mode is mandatory for Fable 5 and Mythos 5. If you do not enable it, the models will not run. There is no configuration that lets you keep Mythos-class inference inside the AWS boundary.

What data gets shared, and for how long?

Your inputs (prompts) and outputs (completions) are retained by Anthropic for up to 30 days. During that window the data may be subject to human review for trust and safety purposes.

Is my data used to train Anthropic's models?

The stated purpose is misuse detection and trust and safety, not training. Anthropic describes the retention as a way to spot patterns of abuse that are not visible in a single exchange. Read the current Mythos-class data-retention policy directly before relying on this for a compliance decision.

Does this requirement apply to Claude Opus 4.8 or Sonnet?

No. Standard Bedrock models default to zero data retention and stay within the AWS boundary. The provider_data_share mandate is specific to the Mythos-class tier, currently Fable 5 and Mythos 5.

Which regions support Fable 5 on Bedrock?

At launch, US East (N. Virginia) and Europe (Stockholm), with additional regions expected. Check the Bedrock model availability list for updates.

How do I enable provider_data_share?

Through the Bedrock Data Retention API. There is no console interface for the setting at launch, so it must be set programmatically before the first Mythos-class invocation.