litellm - 💡(How to fix) Fix [Feature]: Configure a Bedrock project / data-retention mode per model in litellm.yaml

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

Add a way to associate a Bedrock model entry in litellm.yaml with a specific Amazon Bedrock project (and, optionally, an explicit data-retention mode), so the proxy can opt a single model or workload into a project-scoped retention policy without touching account-wide settings.

Concretely, a new bedrock litellm_params field, something like:

- model_name: 'claude-fable-5'
  litellm_params:
    model: 'bedrock/global.anthropic.claude-fable-5'
    aws_region_name: 'us-east-1'
    aws_bedrock_project_id: 'proj_xxxxxxxxxxxx'   # NEW: associate the request with a Bedrock project
    # optional, if Bedrock exposes a per-request retention selector:
    # aws_bedrock_data_retention_mode: 'provider_data_share'

LiteLLM would carry that project association on the outbound request in whatever form the Bedrock runtime/data plane expects (a signed header, a project-scoped endpoint, or a request body field), so the project's data_retention mode resolves for that model.

Motivation, pitch

Bedrock resolves a data-retention mode per request in the order project, then account, then model default (first non-inherit value wins), across the modes default, provider_data_share, none, and inherit. Some newer models allow only one mode. A model whose allowed modes are ["provider_data_share"] is unavailable under default, and the call fails:

litellm.BadRequestError: BedrockException - {"message":"data retention mode 'default' is not available for this model"}

The only way to make such a model usable is to opt in to provider_data_share. Doing that account-wide is too broad; it raises the ceiling for every workload on the account. The tighter option is to set provider_data_share on a single Bedrock project and route only that one model through the project, leaving the account on default. That keeps the blast radius to one workload, which matters when a single sensitive model needs provider data sharing but the rest of the account must not.

This is not possible through LiteLLM today. The bedrock provider has no concept of a project or a data-retention mode; searching litellm/llms/bedrock/ for project, data_retention, or provider_data_share returns nothing. The existing bedrock-mantle code path (litellm/llms/bedrock/chat/mantle/transformation.py and litellm/llms/bedrock/messages/mantle_transformation.py) does route to bedrock-mantle.{region}.api.aws, but it only strips the mantle/ prefix and sets the model in the body; it attaches no project identifier.

So there is currently no way to enable a project-scoped retention policy for a single model from the proxy config. The workaround is a separate AWS account or IAM principal carrying an account-level retention setting, plus a dedicated credential per model, which is a lot of moving parts for what is conceptually a per-model option.

Request: a first-class litellm_params field on the bedrock provider to set the Bedrock project (and optionally the data-retention mode), wired so the project's policy applies to the request. The bedrock-mantle path looks like the natural home, since that data plane is where the project concept lives. Happy to help test against a real account if that is useful.

What part of LiteLLM is this about?

Proxy