[Bug]: Responses API forwards client_metadata to custom_openai chat completions

快速结论：当 Codex CLI 通过 LiteLLM 的 /v1/responses 访问一个 custom_openai 后端时，LiteLLM 会把 Responses API 专有的 client_metadata 字段透传到下游 Chat Completions 调用，OpenAI SDK 不认识该参数，于是返回 500。优先排查下游部署是否把 client_metadata 加入了 additional_drop_params。

适用环境：Codex CLI 0.137.0；LiteLLM 1.87.1（Docker 部署）；后端为 custom_openai，指向 Unsloth OpenAI 兼容服务；模型组 qwen3-coder-next。

最快修复方案：对数据库托管的 custom_openai 部署，通过 LiteLLM 模型更新 API 把 client_metadata 写入 additional_drop_params（示例见“解决步骤”）；长期方案是升级到包含 commit 5cf17f9 的 LiteLLM 版本。

注意事项：仅设置 drop_params: true 对这种情况无效；更新 additional_drop_params 时应保留该部署原有的其他条目，否则可能丢失既有参数丢弃配置。未使用数据库管理部署的场景，Issue 未给出验证过的等价处理方式。

问题场景

用户用 Codex CLI 0.137.0 以 wire_api = "responses" 方式连接 LiteLLM，模型组 qwen3-coder-next 实际由 custom_openai 指向自建的 Unsloth OpenAI 兼容服务。LiteLLM 收到 /v1/responses 请求后，需要把它桥接为下游 Chat Completions 调用，过程中把 Responses 专有字段 client_metadata 一并转发，导致请求失败。

报错原文

AsyncCompletions.create() got an unexpected keyword argument 'client_metadata'

Request Failed
Error Code: 500
Message: litellm.InternalServerError: Custom_openaiException - AsyncCompletions.create() got an unexpected keyword argument 'client_metadata'. Received Model Group=qwen3-coder-next

await openai_aclient.chat.completions.with_raw_response.create(
    **data, timeout=timeout
)

原因分析

最可能的原因是 LiteLLM 在 Responses API 到 Chat Completions 的转换桥接中，没有过滤掉仅属于 Responses API 的 client_metadata 字段，而是把它作为关键字参数传给了 OpenAI SDK 的 chat.completions.create()，该方法不接受此参数，于是抛出类型错误并升级为 HTTP 500。Issue 中提到：直接调用 /v1/chat/completions 正常，最小化的 /v1/responses curl 也正常，只有包含 client_metadata 的 Codex CLI 请求失败，进一步指向该字段是触发点。

环境排查

确认 LiteLLM 版本：1.87.1 已知受影响，检查是否已升级到包含 commit 5cf17f9 的版本。
确认模型组对应的部署类型是否为 custom_openai，以及是否由数据库管理（DB-managed deployment）。
确认 litellm_params 中 additional_drop_params 是否已包含 client_metadata，并记录其原有条目。
确认 Codex CLI 配置使用 wire_api = "responses"；Issue 评论中提到把 provider 改为 openai、配置 api_format = "openai" 曾让 Codex 连通，但该做法属于用户经验，未在 Issue 中作为正式方案验证。
确认 drop_params: true 是否已设置——注意即使设置了仍会复现。

解决步骤

先导出环境变量，准备调用模型更新 API：

export LITELLM_BASE_URL="https://your-litellm.example.com"
export LITELLM_ADMIN_KEY="..."

对受影响的 DB-managed custom_openai 部署，PATCH 更新 additional_drop_params：

curl --fail-with-body -X PATCH \
  "$LITELLM_BASE_URL/model/<deployment-id>/update" \
  -H "Authorization: Bearer $LITELLM_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "litellm_params": {
      "additional_drop_params": ["client_metadata"]
    }
  }'

如果该部署的 additional_drop_params 已有其他条目，必须在同一个数组中保留它们，例如：
```
{
  "litellm_params": {
    "additional_drop_params": ["client_metadata", "existing_param"]
  }
}
```
可优先尝试的长期方案：升级 LiteLLM 到包含 commit 5cf17f9 的版本，从代码层面修复该桥接问题。

验证方法

用原先会失败的 Codex CLI 请求（带 client_metadata 的 /v1/responses 调用）再次访问同一模型组，确认不再返回 500，且下游 Chat Completions 调用不再报 unexpected keyword argument 'client_metadata'；同时检查 /v1/chat/completions 路径是否仍正常。