[Bug]: Reasoning still returned in /responses while include_reasoning is set to false

快速结论：当你在 vLLM 的 OpenAI 兼容接口 /responses 中调用带推理能力的模型（如 GLM 5.3+）并设置 include_reasoning: false 时，服务端仍然把 reasoning 内容作为独立的 reasoning 输出块返回，报错表现为 [Bug]: Reasoning still returned in /responses while include_reasoning is set to false。优先排查该 vLLM 版本是否已包含对 /responses 端点的 include_reasoning 处理逻辑。

适用环境：Issue 中仅确认工具是 vLLM，模型为 GLM-5.3-Flash-EXL3-4bpw 一类自带思考且无开关的模型，环境标注为 “Any”，未提供 Python、CUDA、PyTorch、显卡或依赖版本。因此具体版本适配情况需自行核对。

最快修复方案：暂无确认的一步修复方案。Issue 讨论中维护者表示愿意介入排查，但未给出可直接执行的补丁或配置开关。

注意事项：在 /chat/completions 和 /completions 中 include_reasoning: false 已能剥离 reasoning token（见评论中返回的 reasoning_content 字段），而 /responses 端点行为不一致；这说明问题大概率出在端点侧的实现差异，而非模型本身。不要据此认为模型无法关闭思考。

问题场景

用户通过 curl 直接向 vLLM 服务的 OpenAI 兼容端点 /responses 发送请求，模型选用 GLM 系列（如 glm，实际返回模型标识为 GLM-5.3-Flash-EXL3-4bpw），并在请求体中同时传入 reasoning.effort（max 或 none）和 include_reasoning: false。
期望行为是 include_reasoning: false 剥离 reasoning token，但响应里仍出现类型为 reasoning 的输出块，且其 content[].type 为 reasoning_text。同一模型换用 /chat/completions 却表现正常，且 reasoning_effort 为 none 时在 /responses 上同样不生效。

报错原文

[Bug]: Reasoning still returned in /responses while include_reasoning is set to false

include reasoning must strip reasoning tokens yet it doesnt in /responses, in /chat/completions and /completions it does

"reasoning": {
  "effort": "none"
},
"include_reasoning": false
doesnt work either, in models like glm 5.3+ that come with no switch to turn thinking off it will merge the reasoning into text content.

include_reasoning must support /responses too

原因分析

可能原因：/responses 端点没有复用 /chat/completions、/completions 中已有的 include_reasoning 过滤逻辑，导致 reasoning token 在响应组装阶段仍被输出为独立的 reasoning 块。
评论对比显示，对同一模型、同样的 include_reasoning: false，/chat/completions 返回的 message 中 reasoning_content 仍存在（即 service 层保留），而 /responses 则是把 reasoning 作为顶层 output 项输出，行为差异更可能来自各端点的响应构造路径不同。
另外用户指出，对 GLM 5.3+ 这类“没有关闭思考开关”的模型，如果不剥离，reasoning 可能被合并进 text content，进一步影响下游解析。
由于 Issue 未提供 vLLM 具体版本与打包依赖，上述均为推断，非官方确认结论。

环境排查

确认 vLLM 版本：是否已包含修复 /responses 端点 include_reasoning 的提交。
确认部署的模型：是否为本 Issue 涉及的 GLM 5.3+ 系列（实际返回 GLM-5.3-Flash-EXL3-4bpw）。
确认 OpenAI 兼容 API 的启用方式：是否通过 vllm serve 或等价命令暴露 /responses 端点。
记录返回 usage.output_tokens_details.reasoning_tokens：本次响应为 215，说明 reasoning token 确实被计入并输出。
Issue 未给出 Python、CUDA、PyTorch、显卡信息，不在此处假设，如有需要请从实际环境读取。

解决步骤

先用评论中给出的两次 curl 复现：对 /chat/completions 与 /responses 分别发送同样带有 include_reasoning: false 的请求，确认两个端点的返回差异，作为对照基线。
检查当前 vLLM 版本是否早于 Issue #56428 关闭时间（2026-09-11T15:58:48Z）的上游改动；如确认缺失，可优先尝试升级到包含该修复的版本或对应 commit（可优先尝试，非 Issue 已明确验证的一步修复）。
在修复版本落地前，若下游流程无法处理 reasoning 输出块，可优先在客户端侧对 /responses 返回的 output[] 做过滤，丢弃 type == "reasoning" 的项，仅保留 type == "message" 的项（可优先尝试，属客户端兜底）。
若业务不依赖 /responses，可暂时改用 /chat/completions，该端点在评论中已验证 include_reasoning: false 的返回行为符合用户预期。
若必须在 /responses 上获得正确语义，建议在 Issue #56428 下追加你的 vLLM 版本、模型名与最小复现 curl，便于维护者定位端点侧实现差异。

验证方法

修复后，对同一 /responses 请求（model 为 GLM 系列、reasoning.effort 为 max 或 none、include_reasoning: false），检查返回 JSON 中 output[] 是否不再包含 type == "reasoning" 的项，同时 usage.output_tokens_details.reasoning_tokens 是否为 0 或不被计入。
若暂时只做了客户端过滤兜底，则应确认最终传给业务逻辑的内容中不再包含 reasoning 文本。