[Bug]: aws_bedrock_project_id sent as wrong header (“anthropic-workspace”) to Bedrock Mantle — should be “anthropic-workspace-id”

快速结论：这个报错通常出现在通过 LiteLLM Proxy 调用 AWS Bedrock Mantle 的 Anthropic 兼容接口（bedrock/mantle/anthropic.*）并配置了 aws_bedrock_project_id 时。由于项目 ID 被写进了错误的请求头 anthropic-workspace，Mantle 无法识别该项目，请求会退回账号级数据保留设置，从而在需要显式 provider_data_share 的模型上报错。

适用环境：Issue 中确认的环境为 LiteLLM v1.90.0，问题模块为 Proxy，涉及 AWS Bedrock Mantle 的 Anthropic 兼容端点。Issue 未提供操作系统、Python、CUDA、显卡或依赖版本信息。

最快修复方案：暂无确认的一步修复方案。社区已提交修复 PR（#31994、#31956），将请求头由 anthropic-workspace 改为 anthropic-workspace-id，并同步更新了锁定旧名的测试，但在 Issue 关闭时仍等待维护者审核合并，尚未作为已发布版本中的验证方案确认。

注意事项：该修复目前属于社区 PR，合并状态与发布版本需要你自行核对；在合并前，任何规避手段都可能只是临时措施。修改请求头名称属于协议层行为，不建议自行改写 LiteLLM 源码，除非你清楚维护成本与升级冲突风险。

问题场景

用户在 LiteLLM Proxy 中配置了一个 AWS Bedrock Mantle 的 Anthropic 兼容模型，例如 model: bedrock/mantle/anthropic.claude-fable-5，并在 litellm_params 中设置了 aws_bedrock_project_id: proj_xxxxxxxxxxxx，同时该 Bedrock 项目的数据保留模式已正确设置为其所需的模式（如 Fable 5 要求 provider_data_share）。随后调用 /v1/messages 时，请求返回与数据保留模式相关的错误，表现为项目设置未被生效。

报错原文

BedrockException - {"type":"error","request_id":"req_...","error":{"type":"invalid_request_error","message":"data retention mode 'default' is not available for this model"}}

核心问题描述保留原文：

[Bug]: aws_bedrock_project_id sent as wrong header ("anthropic-workspace") to Bedrock Mantle — should be "anthropic-workspace-id"

原因分析

最可能的原因是：LiteLLM 在向 Bedrock Mantle 的 Anthropic surface 发送请求时，把 aws_bedrock_project_id 放进了名为 anthropic-workspace 的 HTTP 请求头，而 Mantle 期望的请求头名称是带 -id 后缀的 anthropic-workspace-id。请求头名称不匹配时，Mantle 会忽略该字段，请求因而按账号级数据保留设置执行，而不是按项目设置执行。

因此，即便 Bedrock 项目（proj_...）已正确配置为 provider_data_share，对于要求显式数据保留模式的模型（例如 allowed_modes 为 ["provider_data_share"]、不允许隐式默认模式的模型）调用仍会失败，报出的错误看起来与项目配置无关。该问题影响 Mantle 的 chat 和 messages 两条路径（评论中提到的两处 surface）。

环境排查

确认 LiteLLM 版本：Issue 报告为 v1.90.0；如果你在其他版本上遇到相同报错，需要先确认该版本是否已包含 anthropic-workspace-id 相关改动。
确认调用路径：模型是否配置为 bedrock/mantle/anthropic.*，是否通过 Proxy 的 /v1/messages 或 Mantle chat 路径发起调用。
确认 litellm_params 中是否设置了 aws_bedrock_project_id，且取值形如 proj_...。
确认 AWS 区域设置（Issue 中使用 us-east-1）与 Bedrock 项目配置一致。
确认 Bedrock 项目的数据保留模式是否确为模型要求的显式模式（如 provider_data_share），用于区分“项目未生效”还是“项目模式本身配置错误”。
Issue 未提供操作系统、Python、CUDA、PyTorch、显卡及其他依赖版本，这些项目无需作为本问题的排查前提。

解决步骤

先确认当前 LiteLLM 版本是否为 Issue 中的 v1.90.0 或存在同类问题的版本；记录版本号便于与修复 PR 对照。
检查触发问题的模型配置，确认其中包含 aws_bedrock_project_id，且模型指向 Mantle Anthropic 兼容端点。
核对 Bedrock 项目的实际数据保留设置：如果模型要求显式模式（例如 provider_data_share），应确保项目已配置为该模式，排除“项目本身设置错误”这一干扰因素。
关注并核对社区修复 PR：#31994 与 #31956。这两个 PR 将请求头由 anthropic-workspace 更正为 anthropic-workspace-id，并覆盖 Mantle chat 与 messages 两条路径，同时更新了锁定旧名称的测试。
在修复合并并进入你使用的版本之前，可优先尝试的临时方案是：将 LiteLLM 升级到包含该修复的版本，或按 PR 内容核对/应用请求头修正；但该修复在 Issue 关闭时仍等待维护者审核合并，因此并不保证开箱可用。
若必须自行验证，可在测试环境中对 anthropic-workspace 相关代码路径做最小改动并重新运行相关测试，但不要在生产环境直接改源码，以免后续升级冲突。

验证方法

在应用修复后，重新对配置了 aws_bedrock_project_id 的 Mantle Anthropic 模型调用 /v1/messages。如果请求不再返回 data retention mode 'default' is not available for this model，而是按项目的数据保留模式正常返回，即可认为请求头问题已解决。也可通过抓包或日志确认实际发出的请求头名称为 anthropic-workspace-id，而不是 anthropic-workspace。由于修复 PR 在 Issue 关闭时尚未合并，建议以你实际使用的 LiteLLM 版本行为为准进行验证。