OpenAI GPT-5.6 tool calls fail during ocr review because Chat Completions is used

[JH-Wen]

OpenCodeReview Version

v1.8.0 (commit: e670b3b, built: 2026-07-28T02:27:56Z)

Operating System

Windows

Installation Method

npm (global)

LLM Provider

OpenAI

Bug Description

When the built-in OpenAI provider is configured with gpt-5.6-terra, ocr review completes the planning phase but fails when a review subtask sends function tools.

The request is sent to /v1/chat/completions. OpenAI then returns a 400 error stating that function tools with reasoning effort are not supported for this model through Chat Completions and that /v1/responses should be used instead.

This is difficult for a new user to diagnose because:

• gpt-5.6-terra is not included in the built-in OpenAI model presets.
• The configuration flow does not explain that GPT-5.6 models need the Responses API for the tool-calling workflow used by ocr review.
• The review plan can complete successfully before the tool-using subtask fails.
• I could not find a FAQ entry explaining this error or how to configure the Responses API.

The same support is needed for the current GPT-5.6 variants:

• gpt-5.6-luna
• gpt-5.6-terra
• gpt-5.6-sol

Steps to Reproduce

1. Run ocr config provider.
2. Select the built-in OpenAI provider and configure an OpenAI API key.
3. Run ocr config model.
4. Manually add gpt-5.6-terra, because it is not present in the built-in model list.
5. Run ocr review on a repository containing reviewable changes.
6. Wait for the review plan to complete.
7. Observe that the following tool-using subtask fails with a 400 response from /v1/chat/completions.

Expected Behavior

A user selecting a supported GPT-5.6 model should be able to run ocr review without manually knowing which OpenAI API protocol is required.

Ideally, the built-in OpenAI configuration should:

• Include gpt-5.6-luna, gpt-5.6-terra, and gpt-5.6-sol.
• Use the Responses API for these models when no explicit protocol override is configured.
• Preserve the existing behavior of other OpenAI models and configurations.

At minimum, if the selected provider and model combination cannot support the tool-calling workflow, the configuration or connectivity test should fail early with an actionable message instead of failing after the review plan has completed.

Logs / Error Output

[ocr] Plan completed for path/to/file
[ocr] Subtask error for path/to/file: LLM completion error: POST "https://api.openai.com/v1/chat/completions": 400 Bad Request {
    "message": "Function tools with reasoning_effort are not supported for gpt-5.6-terra in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none'.",
    "type": "invalid_request_error",
    "param": "reasoning_effort",
    "code": null
}

Additional Context

OpenCodeReview already supports the Responses API through the openai-responses protocol, introduced in:

• feat: Add OpenAI Responses API support and refactor protocol handling #363

Documentation for the openai-responses protocol is also being tracked in:

• docs(configuration): document openai-responses protocol in Custom Providers section #556

However, this capability is not discoverable through the normal built-in OpenAI provider and model-selection flow. The current FAQ also does not provide troubleshooting guidance for this error. This leaves new users without an actionable recovery path after the failure.

One possible solution would be to add the three exact GPT-5.6 model IDs to the built-in OpenAI provider and associate them with the Responses protocol through explicit per-model metadata. Existing models could continue using the provider's current default protocol, and an explicitly configured protocol could continue to take precedence.

Another option would be a separate built-in OpenAI Responses provider, although users selecting the ordinary OpenAI provider could still encounter the same configuration trap.

Setting reasoning_effort to none may bypass this particular API restriction, but it disables reasoning rather than addressing the protocol mismatch. Adding a first-class reasoning_effort setting is not part of this report.

I have not started an implementation yet and would be happy to submit a focused change with tests and documentation after the preferred approach is confirmed.

[JH-Wen]

中文版

以下为 Issue 正文的中文翻译，便于中文读者参与讨论。

OpenCodeReview 版本

v1.8.0（commit：e670b3b3，built：2026-07-28T02:27:56Z）

操作系统

Windows

安装方式

npm（全局安装）

LLM Provider

OpenAI

Bug 描述

当内置 OpenAI provider 配置为 gpt-5.6-terra 时，ocr review 可以完成规划阶段，但会在 review 子任务发送 function tools 时失败。

请求被发送到 /v1/chat/completions。随后 OpenAI 返回 400 错误，说明该模型不支持通过 Chat Completions 同时使用 function tools 和 reasoning effort，应改用 /v1/responses。

这个问题对新用户尤其难以排查，原因包括：

• gpt-5.6-terra 没有包含在内置 OpenAI 模型预设中。
• 配置流程没有说明，GPT-5.6 模型在 ocr review 使用工具调用时需要使用 Responses API。
• review plan 可以成功完成，但随后使用工具的子任务才会失败。
• 我没有找到解释该错误或说明如何配置 Responses API 的 FAQ 条目。

当前的其他 GPT-5.6 型号也需要得到相同支持：

• gpt-5.6-luna
• gpt-5.6-terra
• gpt-5.6-sol

复现步骤

1. 运行 ocr config provider。
2. 选择内置 OpenAI provider，并配置 OpenAI API key。
3. 运行 ocr config model。
4. 手动添加 gpt-5.6-terra，因为它不在内置模型列表中。
5. 在包含可 review 变更的仓库中运行 ocr review。
6. 等待 review plan 完成。
7. 可以观察到，随后使用工具的子任务收到来自 /v1/chat/completions 的 400 响应并失败。

预期行为

用户选择受支持的 GPT-5.6 模型后，应当能够运行 ocr review，而不需要事先了解或手动配置 OpenAI API 协议。

理想情况下，内置 OpenAI 配置应当：

• 包含 gpt-5.6-luna、gpt-5.6-terra 和 gpt-5.6-sol。
• 在没有显式 protocol 覆盖配置时，让这些模型使用 Responses API。
• 保留其他 OpenAI 模型和现有配置的当前行为。

至少，如果所选 provider 和模型组合不能支持工具调用工作流，配置过程或连接测试应尽早失败并提供可操作的错误信息，而不是等到 review plan 完成后才失败。

日志 / 错误输出

[ocr] Plan completed for path/to/file
[ocr] Subtask error for path/to/file: LLM completion error: POST "https://api.openai.com/v1/chat/completions": 400 Bad Request {
    "message": "Function tools with reasoning_effort are not supported for gpt-5.6-terra in /v1/chat/completions. To use function tools, use /v1/responses or set reasoning_effort to 'none'.",
    "type": "invalid_request_error",
    "param": "reasoning_effort",
    "code": null
}

补充信息

OpenCodeReview 已通过 openai-responses 协议支持 Responses API，该能力由以下 PR 引入：

• feat: Add OpenAI Responses API support and refactor protocol handling #363

openai-responses 协议的文档缺失也正在以下 Issue 中跟踪：

• docs(configuration): document openai-responses protocol in Custom Providers section #556

但是，目前无法通过常规的内置 OpenAI provider 和模型选择流程发现这一能力。现有 FAQ 也没有提供该错误的排查说明，导致新用户在失败后没有可操作的恢复路径。

一种可能的解决方案，是把三个准确的 GPT-5.6 模型 ID 添加到内置 OpenAI provider，并通过显式的 per-model 元数据将它们关联到 Responses 协议。现有模型可以继续使用 provider 当前的默认协议，而用户显式配置的 protocol 仍然可以保持更高优先级。

另一种方案是新增一个独立的内置 OpenAI Responses provider。不过，选择普通 OpenAI provider 的用户仍可能遇到相同的配置陷阱。

将 reasoning_effort 设置为 none 可能绕过这一特定 API 限制，但这实际上是关闭 reasoning，而不是解决协议不匹配问题。本报告不包含新增一等 reasoning_effort 配置项的提议。

我尚未开始实现；在确认首选方案后，我愿意提交一个包含测试和文档的聚焦修改。

[Ritvvvik]

Hi @JH-Wen,

I looked into this issue and I believe the root cause is that GPT-5.6 models require the OpenAI Responses API for tool-calling workflows with reasoning enabled, but the current built-in OpenAI provider flow uses the Chat Completions API (/v1/chat/completions).

The possible solutions I see are:

1. Add first-class support for GPT-5.6 models:

   • Add gpt-5.6-luna, gpt-5.6-terra, and gpt-5.6-sol to the built-in OpenAI model list.
   • Configure these models to use the openai-responses protocol by default.
   • Keep the existing behavior unchanged for other OpenAI models.

2. Add automatic protocol selection:

   • Detect GPT-5.6 models and automatically use the Responses API when no explicit protocol override is provided.
   • Continue respecting any user-defined protocol configuration.

3. Add earlier validation:

   • If a GPT-5.6 model is configured with an incompatible protocol, show an actionable error during configuration instead of failing later during the review process.

I think the first approach would provide the best user experience because users selecting a supported GPT-5.6 model through the built-in provider would not need to know about API protocol differences.

Would you be okay with me raising a PR for this approach? I would be happy to implement the changes along with tests and documentation updates.

[lizhengfeng101]

Thanks @JH-Wen for this excellent bug report — the detailed reproduction steps and analysis made it very easy to understand the root cause. This kind of feedback is incredibly valuable for the project.

We've created a tracking issue for the fix: #573. It covers adding the GPT-5.6 models to the built-in presets and automatically selecting the openai-responses protocol so users don't need to know the underlying API details.

@Ritvvvik Thanks for looking into this as well! We've created #573 to track the implementation. Would you be interested in picking this up? If so, I'd be happy to assign it to you.

[Ritvvvik]

Hi @lizhengfeng101 I'd be happy to take issue #573

[lizhengfeng101]

Hi @lizhengfeng101 I'd be happy to take issue #573

ok，reply in #573 please