DeepAI Paper API 中转站,Cherry Studio 教程,OpenAI Compatible API,客户端接入,错误排查 Cherry Studio 接入 DeepAI API 中转站：GPT-5 reasoning.effort 400 怎么排查

Cherry Studio 接入 DeepAI API 中转站：GPT-5 reasoning.effort 400 怎么排查

2026年5月31日2026年5月31日| DeepAI Paper 编辑部DeepAI Paper 编辑部| 0 Comment| 下午11:39
Cherry Studio 接入 DeepAI API 中转站：GPT-5 reasoning.effort 400 怎么排查 post thumbnail image
Categories:

Cherry Studio 通过 DeepAI API 中转站 接入 OpenAI-compatible Provider 时，模型名写对并不等于所有参数都能通用。GPT-5 系列引入了更细的 reasoning effort 控制，能让开发者在速度、成本和推理质量之间做取舍。但如果客户端把 reasoning.effort 发给不支持该参数的模型，就会直接返回 400。

Cherry Studio 接入 DeepAI API 中转站 GPT-5 reasoning effort 400 排查流程
GPT-5 reasoning 参数要按模型能力发送：不是所有以 gpt-5 开头的模型都接受 reasoning.effort。

问题背景：GPT-5 effort 档位和模型例外

这个问题来自 Cherry Studio Issue #9013。用户指出，GPT-5、GPT-5 mini、GPT-5 nano 支持 minimal、low、medium、high 四个 reasoning effort 档位，但 Cherry Studio 当时的图形界面只提供三个档位。随后用户又补充：gpt-5-chat-latest 不支持设置 reasoning.effort，会返回 Unsupported parameter: 'reasoning.effort'。

相关修复在 Cherry Studio PR #8945 中合并，PR 标题为 fix: support gpt-5，并关闭了 #9013 等多个 GPT-5 支持问题。对使用 DeepAI API 中转站的用户来说，这个案例说明：中转站负责统一入口和日志，但客户端仍然要按模型能力生成正确请求体。

为什么“关闭思考”不一定等于 minimal

Issue 评论里还有一个细节很有价值：如果 UI 里的“关闭”只是“不发送 reasoning.effort 参数”，模型可能会使用默认值，例如默认 medium。这会让用户误以为自己关闭了推理，实际却比低档位消耗更多 reasoning tokens。更合理的做法是：如果用户选择最低推理，应明确发送 minimal；如果目标模型不支持该参数，则完全不发送。

{
  "model": "gpt-5",
  "messages": [
    {"role": "user", "content": "把这段技术说明改写成 SEO 标题"}
  ],
  "reasoning": {
    "effort": "minimal"
  }
}

这个请求适合 GPT-5 系列里支持 reasoning 控制的模型。对于 gpt-5-chat-latest 这类不支持 reasoning.effort 的模型，则应该移除该字段：

{
  "model": "gpt-5-chat-latest",
  "messages": [
    {"role": "user", "content": "把这段技术说明改写成 SEO 标题"}
  ]
}

DeepAI API 中转站里怎么定位这个问题

如果 Cherry Studio 接入 DeepAI API 中转站后出现 reasoning.effort 相关 400，不要先怀疑 Key 或 Base URL。建议按下面步骤排查：

  1. 确认 Provider 类型是 OpenAI Compatible，Base URL 填 https://api.deepai.wang/v1，不要填完整接口路径。
  2. 在 DeepAI API 中转站日志里找到失败请求，查看模型 ID 和请求体是否包含 reasoning.effort。
  3. 如果模型是 gpt-5、gpt-5-mini、gpt-5-nano，优先确认 effort 值是否为 minimal、low、medium、high 之一。
  4. 如果模型是 gpt-5-chat-latest 或中转站后台标注不支持 reasoning 参数的模型，应关闭该参数注入。
  5. 升级 Cherry Studio 到包含 PR #8945 后续修复的版本，再重新测试同一模型。

推荐的模型能力表

对团队或站长来说，最稳的方式不是靠用户记忆每个模型的参数，而是在 DeepAI API 中转站的接入文档里列一个能力表。Cherry Studio、Dify、OpenClaw、n8n 都可以参考这张表决定是否传参。

gpt-5              reasoning.effort: minimal/low/medium/high
gpt-5-mini         reasoning.effort: minimal/low/medium/high
gpt-5-nano         reasoning.effort: minimal/low/medium/high
gpt-5-chat-latest  不发送 reasoning.effort
其他兼容模型        以 DeepAI 中转站后台模型说明为准

如果你维护的是自定义中转层，也可以在网关里做轻量保护：当目标模型不支持 reasoning 参数时，过滤掉 reasoning 字段；当目标模型支持时，校验 effort 是否在允许枚举内。这样能减少客户端版本不一致造成的 400。

常见坑位

  • 按模型名前缀粗暴判断：gpt-5-chat-latest 虽然以 GPT-5 开头，但不一定支持 reasoning.effort。
  • 关闭等于不传参：不传参可能使用默认 medium，不等于 minimal，也不一定更省。
  • 把 Responses API 文档直接套到所有端点：DeepAI API 中转站上的 OpenAI-compatible Chat Completions 也要看具体模型和上游能力。
  • 只看客户端弹窗：真正的错误信息通常在中转站日志里，包括 param、code 和上游返回体。
  • 没有区分成本场景：SEO 标题、格式化、短摘要适合 minimal；多步分析、代码 Agent 和复杂工具调用适合 medium 或 high。

DeepAI API 中转站的实战价值

DeepAI API 中转站在这个问题里的价值是把“模型能力”和“请求实况”都变得可见。用户在 Cherry Studio 里只看到一个 400 弹窗，但站长可以在中转站日志里确认：请求发到哪个模型、是否携带 reasoning.effort、上游返回的 unsupported_parameter 指向哪个字段。这样排查就从猜测变成证据链。

如果你的目标是做 DeepAI API 中转站 的 SEO，建议把这类 GitHub 已解决问题写成“客户端 + 模型 + 参数 + 日志”的教程。搜索“Cherry Studio GPT-5 reasoning effort 400”“gpt-5-chat-latest unsupported reasoning.effort”“OpenAI Compatible reasoning 参数”的用户，通常已经有真实接入需求，给他们一条可复现排查路径，比泛泛介绍模型更容易转化。

参考资料

总结

Cherry Studio 接入 DeepAI API 中转站调用 GPT-5 系列时，reasoning.effort 不是一个可以无脑发送的通用参数。对 gpt-5、gpt-5-mini、gpt-5-nano，可以按需求选择 minimal、low、medium、high；对 gpt-5-chat-latest 等不支持的模型，应直接移除该参数。升级 Cherry Studio，并用 DeepAI API 中转站日志核对请求体，是解决这类 400 的最快路径。

Related Post