[BUG] DeepSeek V4 Pro via OpenAI proxy: error "reasoning_content must be passed back" (400)

[Anthony-Perriolat]

Problem (one or two sentences)

Describe the bug
When using DeepSeek V4 Pro (deepseek-v4-pro) through the OpenAI-compatible proxy provider in RooCode, the API returns a 400 error after the first assistant response:

The reasoning_content in the thinking mode must be passed back to the API.

The error occurs even if I haven’t explicitly enabled any “thinking” mode. It seems the proxy mode does not automatically preserve the reasoning_content field required by DeepSeek’s API for models with built‑in reasoning.

Expected behavior
The proxy mode should either automatically preserve and resend reasoning_content (as the native DeepSeek provider now does in v3.36.10+), or provide a way to disable the reasoning/thinking feature entirely via configuration.

Environment

Extension version: 3.53.0

VS Code / Cursor version: (please fill)

OS: (please fill)

Model: deepseek-v4-pro

Provider: openai (proxy)

Questions / help needed

Is there a way to properly disable the thinking/reasoning mode for deepseek-v4-pro when using the OpenAI proxy?

Should the automatic reasoning_content handling be extended to the OpenAI proxy mode as well?

Thank you for your work on RooCode!

Context (who is affected and when)

I am aware of the fix introduced in PR #10141 (v3.36.10) for the native DeepSeek provider, but the issue still occurs when using the OpenAI proxy mode.

Similar issues: #10171, #9744, #4506.

I tried adding "thinking": {"type": "disabled"} in the request body via extra_body in the provider settings, but RooCode does not seem to forward this parameter in proxy mode.

Reproduction steps

To Reproduce

RooCode extension version: 3.53.0

Provider: openai (proxy)

Model: deepseek-v4-pro

API endpoint: https://api.deepseek.com/v1 (standard OpenAI compatible)

Start a conversation – first assistant response works.

On the next user message, the request fails with the 400 error.

Expected result

the request fails with the 400 error.

Actual result

400

Variations tried (optional)

No response

App Version

3.53.0

API Provider (optional)

DeepSeek

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I have analyzed this issue and here is my proposed implementation plan:

Root Cause

When using DeepSeek V4 Pro via the OpenAI proxy provider, the OpenAiHandler.createMessage() in src/api/providers/openai.ts (line 92) determines whether to use R1 format (which preserves reasoning_content) with this check:

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

deepseek-v4-pro does not match "deepseek-reasoner", so the handler uses convertToOpenAiMessages instead of convertToR1Format. The standard OpenAI format converter does not preserve the reasoning_content field on assistant messages. When the next request is sent to the DeepSeek API, the missing reasoning_content triggers the 400 error.

The native DeepSeekHandler (src/api/providers/deepseek.ts) already handles this correctly by using convertToR1Format with mergeToolResultText for thinking models.

Proposed Fix

1. Extend auto-detection in src/api/providers/openai.ts: Add a helper method _isDeepSeek(baseUrl) that detects when the base URL points to deepseek.com. Update the deepseekReasoner check on line 92 to also trigger R1 format when the base URL is DeepSeek:

const isDeepSeekProxy = this._isDeepSeek(modelUrl)
const deepseekReasoner = modelId.includes("deepseek-reasoner") || enabledR1Format || isDeepSeekProxy

2. Enable mergeToolResultText: When isDeepSeekProxy is detected, pass { mergeToolResultText: true } to convertToR1Format (matching what the native DeepSeek handler does). This prevents environment_details text after tool_results from creating user messages that cause DeepSeek to drop reasoning_content.

3. Add tests: Add test cases in src/api/providers/__tests__/openai.spec.ts to verify that:

   • When openAiBaseUrl contains deepseek.com, R1 format is used automatically
   • The mergeToolResultText option is enabled for DeepSeek proxy URLs
   • The existing openAiR1FormatEnabled flag continues to work as before

This approach is minimal and backwards-compatible: it only changes behavior when the OpenAI proxy base URL explicitly points to DeepSeek, and users can still use the manual openAiR1FormatEnabled toggle for other providers.

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

[MaxOTS]

It is due to https://api-docs.deepseek.com/guides/thinking_mode

https://github.com/dirac-run/dirac works well with the new deepseek models