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

[L4Walk]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When using Claude Code connected through AWS Bedrock, every prompt fails with:

API Error: 400 data retention mode 'default' is not available for this model

This appears similar to other Bedrock compatibility issues where Claude Code sends API parameters (e.g., thinking.type.enabled, output_config.effort, beta flags) that the Bedrock endpoint does not recognize for certain model configurations.

The error occurs immediately on any message (e.g., hi), making Claude Code completely unusable via Bedrock.

What Should Happen?

Claude Code should either:

• Not send the data_retention parameter when the model/Bedrock configuration doesn't support it, OR
• Gracefully handle the error and suggest a workaround

Expected: Normal conversation flow without 400 errors.

Error Messages/Logs

API Error: 400 data retention mode 'default' is not available for this model

Steps to Reproduce

1. Configure Claude Code to use AWS Bedrock (export CLAUDE_CODE_USE_BEDROCK=1)
2. Run claude and send any message, e.g., hi
3. Error: ⏺ API Error: 400 data retention mode 'default' is not available for this model

Claude Model

Model: global.anthropic.claude-fable-5

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.170

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. v2.1.116 fails with Bedrock: output_config.effort not permitted #51377
2. Bedrock: thinking.type.enabled not supported by newer models behind inference profile ARNs #51439
3. [Bug] Opus 4.8 on Bedrock: "thinking.type.enabled" not supported — regression from #51439 #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

[jwhitcraft]

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/

[darshil]

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

[yurukusa]

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]

@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.

[sandeep-equal]

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.