[BUG] API Error 400: data retention mode 'default' is not available for this model via AWS Bedrock

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/51377
2. https://github.com/anthropics/claude-code/issues/51439
3. https://github.com/anthropics/claude-code/issues/63546

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The fix that worked to get Fable running is this:

awscurl --service bedrock --region us-east-2 -X PUT \
  https://bedrock.us-east-2.amazonaws.com/data-retention \
  -d '{ "mode": "provider_data_share" }'

But that breaks all the other models, so...

EDIT: So this seem to be by design: https://aws.amazon.com/blogs/aws/anthropic-claude-fable-5-on-aws-mythos-class-capabilities-with-built-in-safeguards-now-available/

@jwhitcraft How does enabling the data retention policy for Fable break other models? What's exactly breaking?

This one looks like a different root cause from the usual Bedrock "Claude Code sends a field Bedrock rejects" 400s (e.g. output_config.effort / eager_input_streaming → Extra inputs are not permitted). Those are schema rejections; this error is a model-specific data-retention requirement, and it lines up with the model in the report being a Fable 5 / Mythos-class model.

Per AWS's own launch announcement, these models can't be invoked under the default retention mode until you explicitly opt in:

For the Fable 5 model, you must opt into data sharing by using the Data Retention API and setting provider_data_sharing before you can invoke the models. There is no console UI for this setting at launch.

— https://aws.amazon.com/blogs/aws/anthropic-claude-fable-5-on-aws-mythos-class-capabilities-with-built-in-safeguards-now-available/ (see also the data-retention note: https://support.claude.com/en/articles/15425996-data-retention-practices-for-mythos-class-models )

So data retention mode 'default' is not available for this model is Bedrock rejecting a default-retention request for a model that requires the opt-in — not (only) Claude Code sending an unsupported param. hi failing immediately fits, because the rejection happens at invoke time regardless of prompt.

Important caveat before opting in: that opt-in means Bedrock retains and shares your inference data (~30 days, for safety review), and per AWS "your data will leave AWS's data and security boundary." If you're on Bedrock specifically for ZDR / compliance reasons, do not just flip it on.

Side-effect-free workaround if you don't specifically need Fable 5: pin Claude Code to a model that works under default retention (Sonnet 4.6 / Opus 4.x) and confirm whether the error disappears — that also isolates it to the model:

export ANTHROPIC_DEFAULT_SONNET_MODEL='us.anthropic.claude-sonnet-4-6'
export ANTHROPIC_DEFAULT_OPUS_MODEL='us.anthropic.claude-opus-4-8'

If a non-Fable model works and Fable 5 doesn't, that confirms the retention-opt-in cause rather than a generic param issue.

(I haven't seen Claude Code's internal request building, so I can't say exactly what it sends on the wire — but the AWS-side requirement above fully accounts for the default rejection, and the model card / announcement are the authority here. One genuinely actionable ask for the maintainers would be a clearer error that points to the Data Retention API opt-in when a Mythos-class model is selected, instead of a bare 400.)

@jwhitcraft How does enabling the data retention policy for Fable break other models? What's exactly breaking?

@darshil the other models on bedrock-runtime (didn't test mantle) just stated failing with a 500 sever side error.

Confirming @yurukusa's root cause from the AWS-side docs, and answering the "why does it break other models" thread from @jwhitcraft / @darshil, since that part is still open.

The Bedrock data-retention docs spell out the mechanism. Your effective retention mode is first non-inherit value of (project → account → model default), and each model declares an allowed_modes list. Fable 5 and Mythos 5 are the only models whose allowed_modes is exactly ["provider_data_share"] — so under the default/inherit mode they resolve to status: "unavailable" and invoke is blocked with the exact string in this issue: This model is not available under data retention mode 'default'. It's a policy gate at invoke time, which is why hi fails instantly. Not a malformed request.

On @jwhitcraft's account-wide PUT breaking the other models: per the docs that shouldn't happen for models whose allowed_modes already includes provider_data_share (e.g. Opus 4.8 is ["default", "provider_data_share"] and should keep working, data retained by AWS only). A 500 rather than a 400/unavailable smells like either eventual consistency after the PUT or a region mismatch — the PUT hit us-east-2 control plane, so worth confirming the models you're invoking resolve their retention in the same region.

The cleaner fix that sidesteps the whole "flip it account-wide" problem is to scope the opt-in to a project instead of the account, and only route Fable 5 through that project:

curl https://bedrock-mantle.us-east-1.api.aws/v1/organization/projects/proj_abc123 \
  -H "x-api-key: $BEDROCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "data_retention": { "mode": "provider_data_share" } }'

Everything outside that project keeps the account default, so your other models are untouched. The docs' "mixed-model projects" section confirms that even within a provider_data_share project, a model only shares data if its own allowed_modes requires it — Opus/Sonnet traffic in that project stays AWS-boundary-only.

Verify before/after with the models endpoint — you want status: available:

curl https://bedrock-mantle.us-east-1.api.aws/v1/models/anthropic.claude-fable-5 \
  -H "x-api-key: $BEDROCK_API_KEY"

Worth repeating @yurukusa's caveat: provider_data_share means prompts/completions are retained and shared with Anthropic (~30 days, safety review) and leave AWS's boundary. If you're on Bedrock specifically for ZDR/compliance, don't flip it — pin a non-Fable model instead, or ask your AWS account manager about per-account ZDR approval for Fable (that adds "none" to the model's allowed_modes).

The genuinely actionable CLI ask stands: when Bedrock returns data retention mode '<x>' is not available for this model, Claude Code could surface the Data Retention API opt-in remedy instead of a bare 400.