issue: Reasoning Effort is never remapped to reasoning.effort on Responses connections

快速结论：当 Open WebUI 里的连接被设置为 API Type = Responses 时，前端仍把 Reasoning Effort 以顶层 reasoning_effort 字段发送，而 /v1/responses 只识别 reasoning.effort 嵌套结构，因此该设置被静默忽略；优先确认请求体字段形态与连接 API Type 是否匹配。

适用环境：Open WebUI v0.12.5（Docker 安装），操作系统 RaspbianOS，浏览器 Chrome；Issue 未提供 Ollama、Python、CUDA 或显卡信息。该问题在最新 release 与 dev 分支均可复现。

最快修复方案：暂无确认的一步修复方案。Issue 关闭时被标记为 duplicate + intended，并提示“use a custom advanced param here”，即按预期需在模型高级参数中手动配置 Responses 所需的 reasoning.effort 自定义参数，而不是依赖 Reasoning Effort 下拉项自动映射。

注意事项：该结论来自 Issue 维护者关闭说明，Issue 未给出具体自定义参数的字段名与取值格式，需以 Responses 接口文档和实际部署版本为准；切回 Chat Completions 时顶层 reasoning_effort 才有效，两种 API Type 不能混用同一套参数形态。

问题场景

用户在 Open WebUI 中把连接的高级设置 API Type 改为 Responses，随后在工作区模型的 Advanced Params 里把 Reasoning Effort 设为 Custom → high 并保存。新建聊天发送消息时，通过浏览器 DevTools 的 Network 面板检查 POST /api/chat/completions 请求体，发现请求中并未出现 Responses 所需的 "reasoning": {"effort": "high"}，而是发送了顶层扁平字段 "reasoning_effort": "high"。同一连接切回 Chat Completions 后，该扁平字段又变成正确行为，说明问题只出现在 Responses 端点下的参数重映射。

报错原文

issue: Reasoning Effort is never remapped to reasoning.effort on Responses connections — silently ignored

Expected: "reasoning": {"effort": "high"}
Actual: "reasoning_effort": "high" — a flat top-level key, which /v1/responses does not define.

原因分析

可能原因是 Open WebUI 在构造发往上游的请求体时，未根据连接的 API Type 区分参数序列化方式：无论 API Type 是 Chat Completions 还是 Responses，都把 Reasoning Effort 输出为顶层 reasoning_effort。而 Responses 接口使用嵌套的 reasoning.effort 结构，顶层扁平字段不被其定义，因此上游静默忽略，既不改行为也不返回明确报错。Issue 中任意值（none、off、high、max、abcd、helloworld!）表现一致，也印证了该参数在 Responses 路径下根本没有被读取。

环境排查

确认 Open WebUI 版本：Issue 报告为 v0.12.5，且 dev 分支同样可复现。
确认连接的 API Type 是否被设置为 Responses（Admin → Settings → Connections → 编辑连接 → 齿轮图标 → Advanced → API Type）。
确认模型 Advanced Params 中 Reasoning Effort 的取值方式（Custom → high）。
用浏览器 DevTools → Network 查看 POST /api/chat/completions 请求体，确认实际发送的是 reasoning_effort 还是 reasoning.effort。
Issue 未涉及 Python、CUDA、PyTorch、显卡或 Ollama 版本，这些项目无需作为排查前提。

解决步骤

先在 DevTools → Network 中复现并抓取一次请求体，确认当前发送字段为顶层 reasoning_effort，且连接 API Type 为 Responses。
按 Issue 关闭说明的思路，在模型的 Advanced Params 中使用自定义高级参数，手动配置 Responses 期望的 reasoning.effort 结构；不要依赖 Reasoning Effort 下拉项在该连接上自动映射。
保存后重新发起一次聊天请求，再次查看请求体，确认参数以 reasoning 对象内嵌 effort 的形式出现，而不是顶层扁平键。
如果仍需使用 Chat Completions 端点，则保持原 Reasoning Effort 设置即可，因为该端点下顶层 reasoning_effort 是正确形态；不要将两种端点的参数配置互相套用。
可优先尝试：对照 Issue 关联的 #31394 中关于 Responses API reasoning 参数与模型/端点差异化处理的讨论，确认当前版本的参数命名支持范围。

验证方法

在 Responses 类型的连接下发送消息，打开 DevTools → Network 检查 POST /api/chat/completions 的请求体：应看到 reasoning 对象内含 effort 字段，而非顶层 reasoning_effort；同时更换不同的 Reasoning Effort 取值，观察上游回复或请求体是否随之变化。若字段形态正确但仍无效果，则需进一步确认上游服务是否支持该参数。