[BUG] Deepseek-r1 request failed in OpenAI Compatible mode.

[supuwoerc]

Problem (one or two sentences)

#10304

I apologize for the five-day delay in submitting this issue. Last week, after updating my ROO code in VS Code, I found that my ROO code could not request Deepseek-R1, with a 400 status code. I tried not using OpenAI Compatible mode, and the request was successful. However, since I'm using a model service built by my company, I still need to use OpenAI Compatible daily.

Thanks to the ROO code team for their efforts.

This is my request after upgrading to version 3.38.0 today, and I'm still getting the same 400 error.

Date/time: 2025-12-29T01:31:54.354Z
Extension version: 3.38.0
Provider: openai
Model: deepseek-r1

400
OpenAI completion error: 400 status code (no body)

Context (who is affected and when)

In the simplest conversation scenario, I tested sending "hi," and the request returned a 400 error.

Reproduction steps

1. I configured the server endpoint set up by my company.

2. I used the correct API key.

3. The request returned a 400 error.

4. I tried using curl to verify if it was a service error, but it wasn't; the service meets the OpenAI Compatible requirements.

5. On my other machine, without the upgraded plugin, requests were successful. The root code configuration files on both computers are identical.

Expected result

Normal conversation and task execution

Actual result

OpenAI completion error: 400 status code (no body)

Variations tried (optional)

No response

App Version

3.38.0

API Provider (optional)

OpenAI Compatible

Model Used (optional)

deepseek-r1

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

Date/time: 2025-12-29T01:33:10.308Z
Extension version: 3.38.0
Provider: openai
Model: deepseek-r1

400
OpenAI completion error: 400 status code (no body)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Problem Analysis

The issue occurs because DeepSeek-R1 models do not support native function calling (tool calling), but the OpenAI Compatible handler in Roo Code sends native tools to these models, causing a 400 error.

Looking at the code:

1. In src/api/providers/openai.ts, the getModel() method (line 293-304) merges NATIVE_TOOL_DEFAULTS which sets supportsNativeTools: true by default for all OpenAI Compatible models
2. The DeepSeek reasoner detection (line 95) uses modelId.includes("deepseek-reasoner"), which does NOT match deepseek-r1
3. Even when R1 format is enabled via openAiR1FormatEnabled, tools are still sent to the API

Proposed Solution

Modify src/api/providers/openai.ts to:

1. Expand DeepSeek reasoner detection to include deepseek-r1 pattern:

   const deepseekReasoner = modelId.includes("deepseek-reasoner") || 
                            modelId.includes("deepseek-r1") || 
                            enabledR1Format

2. Override supportsNativeTools for DeepSeek reasoner models in the getModel() method:

   • When a DeepSeek reasoner model is detected, set supportsNativeTools: false in the returned model info
   • This will prevent native tools from being included in requests to these models
   • The extension will fall back to XML tool protocol for these models

Implementation Details

The fix involves changes to src/api/providers/openai.ts:

override getModel() {
    const id = this.options.openAiModelId ?? ""
    const enabledR1Format = this.options.openAiR1FormatEnabled ?? false
    const isDeepSeekReasoner = id.includes("deepseek-reasoner") || 
                               id.includes("deepseek-r1") || 
                               enabledR1Format
    
    const info: ModelInfo = {
        ...NATIVE_TOOL_DEFAULTS,
        ...(this.options.openAiCustomModelInfo ?? openAiModelInfoSaneDefaults),
        // Override: DeepSeek reasoner models don't support native tool calling
        ...(isDeepSeekReasoner && { supportsNativeTools: false }),
    }
    const params = getModelParams({ format: "openai", modelId: id, model: info, settings: this.options })
    return { id, info, ...params }
}

This approach:

• Maintains backward compatibility for other OpenAI Compatible models
• Specifically handles DeepSeek R1/Reasoner models that don't support native tools
• Uses the existing XML tool protocol as a fallback

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[supuwoerc]

I've analyzed this issue and here's my proposed implementation plan:我已经分析了这个问题，以下是我的实施方案：

Problem Analysis  问题分析

The issue occurs because DeepSeek-R1 models do not support native function calling (tool calling), but the OpenAI Compatible handler in Roo Code sends native tools to these models, causing a 400 error.出现此问题的原因是 DeepSeek-R1 模型不支持原生函数调用（工具调用），但 Roo Code 中的 OpenAI Compatible 处理程序会将原生工具发送到这些模型，从而导致 400 错误。

Looking at the code:查看代码：

1. In src/api/providers/openai.ts, the getModel() method (line 293-304) merges NATIVE_TOOL_DEFAULTS which sets supportsNativeTools: true by default for all OpenAI Compatible models在 src/api/providers/openai.ts 中， getModel() 方法（第 293-304 行）合并了 NATIVE_TOOL_DEFAULTS ，该设置默认为所有 OpenAI 兼容模型的 supportsNativeTools: true
2. The DeepSeek reasoner detection (line 95) uses modelId.includes("deepseek-reasoner"), which does NOT match deepseek-r1DeepSeek 推理器检测（第 95 行）使用了 modelId.includes("deepseek-reasoner") ，这与 deepseek-r1 不匹配。
3. Even when R1 format is enabled via openAiR1FormatEnabled, tools are still sent to the API即使通过 openAiR1FormatEnabled 启用了 R1 格式，工具仍然会发送到 API。

Proposed Solution  建议的解决方案

Modify src/api/providers/openai.ts to:修改 src/api/providers/openai.ts 文件，内容如下：

1. Expand DeepSeek reasoner detection to include deepseek-r1 pattern:**扩展 DeepSeek 推理器检测功能 **，使其包含 deepseek-r1 模式：
   const deepseekReasoner = modelId.includes("deepseek-reasoner") ||
   modelId.includes("deepseek-r1") ||
   enabledR1Format

2. Override supportsNativeTools for DeepSeek reasoner models in the getModel() method:在 getModel() 方法中重写对 DeepSeek 推理器模型的 supportsNativeTools ：

   • When a DeepSeek reasoner model is detected, set supportsNativeTools: false in the returned model info当检测到 DeepSeek 推理器模型时，在返回的模型信息中设置 supportsNativeTools: false
   • This will prevent native tools from being included in requests to these models这将防止将这些模型的请求中包含原生工具。
   • The extension will fall back to XML tool protocol for these models对于这些模型，扩展程序将回退到 XML 工具协议。

Implementation Details  实施细节

The fix involves changes to src/api/providers/openai.ts:此修复涉及对 src/api/providers/openai.ts 的更改：

override getModel() {
const id = this.options.openAiModelId ?? ""
const enabledR1Format = this.options.openAiR1FormatEnabled ?? false
const isDeepSeekReasoner = id.includes("deepseek-reasoner") ||
id.includes("deepseek-r1") ||
enabledR1Format

const info: ModelInfo = {
    ...NATIVE_TOOL_DEFAULTS,
    ...(this.options.openAiCustomModelInfo ?? openAiModelInfoSaneDefaults),
    // Override: DeepSeek reasoner models don't support native tool calling
    ...(isDeepSeekReasoner && { supportsNativeTools: false }),
}
const params = getModelParams({ format: "openai", modelId: id, model: info, settings: this.options })
return { id, info, ...params }

}
This approach:  这种方法：

• Maintains backward compatibility for other OpenAI Compatible models保持对其他 OpenAI 兼容模型的向后兼容性
• Specifically handles DeepSeek R1/Reasoner models that don't support native tools专门处理不支持原生工具的 DeepSeek R1/Reasoner 模型
• Uses the existing XML tool protocol as a fallback使用现有的 XML 工具协议作为备用方案

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.请在评论中表示您同意此方案，我将着手实施。

I think it's better to expose this as a setting to users, allowing them to choose whether to enable or disable the feature, because model names are impossible to exhaustively list, especially for models trained by themselves or those with proxies.

Judging by model name in the code doesn't seem to provide complete coverage.

Providing a configuration option would give users the veto power to disable this feature that causes failures.

@hannesrudolph

[roomote]

I've seen your comment and agree with the suggestion to expose this as a user setting. Rather than trying to detect all model name patterns, a configuration option would give users explicit control to disable native tools when their model doesn't support them. I'll explore the codebase and implement a solution that adds this setting. I'll open a PR to share progress.

[roomote]

Opened a PR with my attempt at addressing this: #10369

The implementation adds a new "Disable native tool calling" checkbox in the OpenAI Compatible provider settings. This gives users explicit control to disable native tools when their model does not support them, addressing the concern that model names cannot be exhaustively detected.

Additionally, the PR expands the automatic DeepSeek reasoner detection to include the deepseek-r1 pattern (alongside the existing deepseek-reasoner pattern).

Feedback welcome!

[lgc0313]

I encountered the same error in OpenAI-compatible mode.