[Bug]: Databricks non-GPT models 400 with reasoning_effort must be a string when reasoning.summary is set

快速结论：当通过 LiteLLM 的 Responses API 向 Databricks 托管的非 GPT 模型（例如 databricks/system.ai.kimi-k3）发送带有 reasoning.summary 的请求时，LiteLLM 桥接层会把 reasoning_effort 保留为完整字典，而不是拆成字符串，导致 Databricks 返回 400：[Bug]: Databricks non-GPT models 400 with reasoning_effort must be a string when reasoning.summary is set。优先排查客户端是否总是同时发送 reasoning.summary 和 reasoning.effort，以及目标模型名是否不含 “gpt”。

适用环境：已确认受影响版本为 litellm==1.100.0（Issue 中标注为团队 pinned tag）。触发路径为 Databricks provider、Responses API 请求、非 GPT 命名的模型（如 databricks/system.ai.kimi-k3）。Issue 中未提供操作系统、Python、CUDA、显卡等环境信息。

最快修复方案：暂无确认的一步修复方案。Issue 中建议在 DatabricksConfig.map_openai_params 中为非 Claude 模型把字典形态的 reasoning_effort 强制转换为 effort 字符串（参考 #25359 对 Anthropic 的处理），但这是建议修复方向，Issue 讨论中未给出已验证的发布版本或补丁。

注意事项：在客户端侧临时省略 reasoning.summary（仅保留 reasoning.effort）在 Issue 中被描述为可以成功，但这只是绕过，不是上游修复；同样，强制模型名包含 “gpt” 也不可行，因为 Databricks 的 Responses API 仅对 GPT 命名模型兼容。升级 LiteLLM 前请确认目标版本是否已合入对应强制转换逻辑。

问题场景

用户通过 LiteLLM 调用 Databricks 托管的模型，使用 Responses API，并向请求体传入 reasoning: {"effort": ..., "summary": ...}。当模型名不含 “gpt”（例如 databricks/system.ai.kimi-k3）时触发报错。Issue 指出，任何在每次请求中总是同时发送 reasoning.summary 与 reasoning.effort 的客户端（例如 Codex CLI）都会在每次调用受影响模型时遇到此问题；仅省略 summary 的请求可以成功。

报错原文

litellm.BadRequestError: DatabricksException - {"error_code":"BAD_REQUEST","message":"{\"error\":\"Bad request: parameter \"reasoning_effort\" must be a string\"}"}

Issue 中另记录了一个相关的、由同一根因引起的独立失败模式：Databricks 的 Qwen3.5 端点 /chat/completions 后端严格拒绝标准 Responses API 的 client_metadata 字段，返回 json: unknown field "client_metadata"。

原因分析

Issue 中给出的根因链路分为三步：

步骤 1：Responses→Chat 转换器（litellm/responses/litellm_completion_transformation/transformation.py 中的 transform_responses_api_request_to_chat_completion_request）在检测到 reasoning_param 含 summary 时，会把整个字典赋给 reasoning_effort，而不是提取 effort 字符串。
步骤 2：Databricks 仅在模型名含 “gpt” 时注册原生 Responses API 配置（litellm/utils.py 中 ProviderConfigManager._get_python_responses_api_config）。非 GPT 模型返回 None，因此请求被路由到 Chat Completions 桥接，无论调用方实际命中哪个端点。
步骤 3：Databricks Chat 转换（litellm/llms/databricks/chat/transformation.py 中 DatabricksConfig.map_openai_params）只对 Claude 模型处理字典形态的 reasoning_effort。对其他模型，字典被原样序列化进请求体，被 Databricks API 拒绝。

Issue 将 client_metadata 失败模式也归到同一“步骤 2”门控上：非 GPT 模型走 Chat Completions 桥接后，client_metadata 字段不被该后端接受。

环境排查

确认 LiteLLM 版本：Issue 已确认 v1.100.0 受影响；受影响区间描述为 #25359 引入保留字典分支之后、Databricks chat 转换获得与 Anthropic 相同强制转换之前。
确认 provider 为 databricks，以及请求是否走 Responses API。
确认目标模型名：非 GPT 命名（如 databricks/system.ai.kimi-k3）会命中此缺陷。
确认请求体是否包含 reasoning.summary；若客户端总是携带该字段（例如 Codex CLI），必然触发。
Issue 未提供操作系统、Python、CUDA、PyTorch、显卡、依赖版本信息，无需补写。

解决步骤

先做最小化复现，确认是桥接层还是 Databricks 端的问题。Issue 给出的第一段最小复现：调用 transform_responses_api_request_to_chat_completion_request，模型设为 databricks/system.ai.kimi-k3，responses_api_request={"reasoning": {"effort": "medium", "summary": "auto"}}，然后打印 request["reasoning_effort"]。若输出为 {'effort': 'medium', 'summary': 'auto'}，说明桥接层保留了完整字典。
再确认 provider 层未做强制转换。Issue 给出的第二段复现：用 DatabricksConfig().map_openai_params 传入 non_default_params={"reasoning_effort": {"effort": "medium", "summary": "auto"}}、model="system.ai.kimi-k3"、drop_params=False，打印 optional_params.get("reasoning_effort")。若仍为原始字典，说明 map_openai_params 未对非 Claude 模型解包。
临时绕过（客户端侧，非上游修复）：在请求中省略 reasoning.summary，仅保留 reasoning.effort。Issue 明确说明省略 summary 时请求可以成功。
可优先尝试应用 Issue 中建议的修复方向：在 DatabricksConfig.map_openai_params 中，对非 Claude 模型把字典形态的 reasoning_effort 强制转换为 effort 字符串，与现有 Claude 专用处理保持一致（与 #25359 对 Anthropic 的修复同形）。请在本地补丁或升级到包含该修复的版本后再验证。
如果同时遇到 client_metadata 被拒的错误，注意这属于同一门控根因的另一症状；Issue 中确认直接调用 Databricks /responses 端点（绕过 LiteLLM）可以成功，而经 LiteLLM 时 Datadog APM trace 显示请求实际落在 /chat/completions。修复方向相同。

验证方法

按 Issue 的验证测试思路：在隔离虚拟环境中安装 litellm==1.100.0 与 pytest（无需凭据或推理调用），运行两个断言——第一，桥接层在 summary 存在时确实把 reasoning_effort 变为完整字典（此为上游输入，属已记录行为）；第二，DatabricksConfig.map_openai_params 对 model="system.ai.kimi-k3" 应把 optional_params.get("reasoning_effort") 变为字符串 "medium"。修复前第二个断言失败，修复后应通过。真实请求层面，可观察向非 GPT Databricks 模型带 reasoning.summary 的调用是否不再返回 400 reasoning_effort must be a string。