[Bug]: Responses WebSocket drops deployment-level default request parameters

快速结论：当 LiteLLM 以代理/路由模式运行，并且你依赖部署级默认参数（如 reasoning_effort）时，通过 Responses WebSocket 发送 response.create 帧会丢失这些默认值，导致上游按内置默认值处理并报错。优先排查 WebSocket 路径是否合并了部署级默认参数。

适用环境：LiteLLM proxy/router 模式；Issue 中确认复现于 LiteLLM v1.89.1。操作系统、Python、CUDA、显卡、依赖版本在 Issue 中均未提及。

最快修复方案：暂无确认的一步修复方案。该 Issue 未给出并可验证的代码级修复，讨论中给出的统一参数解析、传输无关中间件等方向属于改进建议，尚未被确认为已合并的修复。

注意事项：HTTP /v1/responses 路径对同一配置是成功的，因此“HTTP 成功”不能作为 WebSocket 问题已解决的证据。在修复版本发布前，如果必须使用 WebSocket，可在客户端帧中显式携带所需参数，但这会失去代理托管默认值的好处，且不保证覆盖所有部署级默认项。

问题场景

用户在 LiteLLM proxy/router 模式下配置了一个带部署级默认参数的模型，例如给 gpt-5-pro 部署设置 reasoning_effort: high。随后客户端连接 Responses WebSocket 端点，发送不带显式 reasoning 块的普通 response.create 帧。代理虽然选中了正确的部署，但转发给原生 provider WebSocket 时没有把该部署的默认参数合并进去，导致上游 provider 收到自身默认值并拒绝请求。同样的配置走 HTTP Responses 请求时是成功的。

报错原文

{
  "type": "error",
  "status": 400,
  "error": {
    "type": "invalid_request_error",
    "code": "unsupported_value",
    "message": "Unsupported value: medium is not supported with the GPT-5 Pro model. Supported values are: high.",
    "param": "reasoning.effort"
  }
}

原因分析

核心原因是 WebSocket 转发路径与 HTTP 转发路径存在代码路径分叉：HTTP Responses 路由会把部署级默认参数合并进请求，而当前原生 WebSocket 转发路径在确认授权模型后，基本按原样转发客户端帧，未做部署默认值合并。于是客户端帧省略 reasoning 时，部署里配置的 reasoning_effort: high 没有被补上，provider 回落到其默认的 medium，而 GPT-5 Pro 只接受 high，因此返回 400。

讨论中提到的“参数合并应发生在单一规范层，而不是在各传输协议中重复实现”，属于对根因的合理推断与结构性建议，可作为理解方向，但不代表已被验证的具体修复。

环境排查

确认当前运行的是 LiteLLM proxy/router 模式，而非直接调用 SDK。
确认 LiteLLM 版本；Issue 中明确复现于 v1.89.1，若版本不同需单独验证。
确认模型配置中是否使用了部署级默认参数，例如 litellm_params 下的 reasoning_effort。
确认问题是否仅出现在 Responses WebSocket 路径；对照测试同一 proxy 模型配置下的 HTTP /v1/responses 是否成功。
确认客户端发送的 response.create 帧是否省略了相关参数（如 reasoning、service_tier 或其他 provider 特定默认项）。

解决步骤

先确认问题边界：用同一模型配置分别通过 HTTP /v1/responses 和 Responses WebSocket 发送等效请求。如果 HTTP 成功、WebSocket 失败，且失败信息指向部署默认值未生效，则符合本 Issue 特征。
检查代理模型配置，确认部署级默认参数确实写在 litellm_params 中，例如示例里的 reasoning_effort: high。
检查 WebSocket 客户端发送的 response.create 帧，确认它是否省略了 reasoning 等参数。本 Issue 的复现帧正是省略了显式 reasoning 块。
如果业务允许且暂时无法升级/修复，可优先尝试在客户端帧中显式传入 provider 要求的参数（例如显式指定 reasoning），作为绕过 WebSocket 默认值不合并的临时手段。
关注 LiteLLM 上游是否已修复 WebSocket 路径的参数合并逻辑。讨论中提到的方向包括：统一 resolve_params 层、传输无关中间件、以及同时覆盖 HTTP 与 WS 的集成测试；这些可作为判断修复是否合理的参考，但 Issue 中未确认具体落地版本。

验证方法

在应用修复或采用临时绕过方案后，用同一模型配置再次通过 Responses WebSocket 发送不带显式 reasoning 的 response.create 帧。如果部署级默认参数被正确合并，上游不应再返回 unsupported_value 中关于 medium 的错误，请求应正常完成。同时建议对照 HTTP /v1/responses，确认两条路径对等效请求得到一致结果。