Bug: DeepSeek 400 Error "reasoning_content must be passed back" due to malformed history payload

[Mayocampo]

Type: Bug

Bug Description

When using DeepSeek reasoning models (specifically deepseek-v4-pro) with the "Reasoning effort" enabled, multi-turn conversations fail starting on the second turn. The API immediately returns a 400 error stating that the reasoning_content must be passed back.

Upon inspecting the error logs, the issue stems from how Roo Code formats the chat history. Instead of passing reasoning_content as a top-level field in the message object (as required by the DeepSeek API), Roo Code encapsulates it inside the content array with a "type": "reasoning" property.

Environment

• Extension Version: 0.0.8162
• Provider: openai (compatible endpoint) / deepseek native
• Model: deepseek-v4-pro
• OS: Windows / WSL2

Steps to Reproduce

1. Configure Roo Code to use deepseek-v4-pro (either via Native provider or OpenAI Compatible endpoint).
2. Enable "Reasoning effort".
3. Start a new chat and send an initial prompt (e.g., an orchestrator task that requires tool usage).
4. The model responds successfully on the first turn (e.g., thinking, then using a tool like update_todo_list).
5. Roo Code automatically submits the tool_result for the next turn.
6. The request fails immediately with the 400 error.

Expected Behavior

Roo Code should parse its internal reasoning format and map it to the exact structure required by the DeepSeek API when building the history payload.

According to DeepSeek's API documentation, previous assistant messages with reasoning must be formatted as:

{
  "role": "assistant",
  "reasoning_content": "The thinking process here...",
  "content": "The final output here..."
}

Actual Behavior / Error Logs

Roo Code is sending the reasoning block as an item inside a content array, which the DeepSeek API does not recognize, triggering the following error details:

{
  "error": {
    "timestamp": "2026-04-26T01:20:17.261Z",
    "version": "0.0.8162",
    "provider": "openai",
    "model": "deepseek-v4-pro",
    "details": "400\nOpenAI completion error: 400 The `reasoning_content` in the thinking mode must be passed back to the API."
  },
  "history": [
    {
      "role": "assistant",
      "content": [
        {
          "type": "reasoning",
          "text": "El usuario quiere ejecutar el flujo de orquestación completo..."
        },
        {
          "type": "text",
          "text": "LISTO. Diagnosticar todos los Issues abiertos. Luego ejecutar ciclo completo por cada uno."
        },
        {
          "type": "tool_use",
          "id": "call_00_QsFvAqZl348meMiyq5SDDr8j",
          "name": "update_todo_list",
          "input": { ... }
        }
      ]
    }
  ]
}

Suggested Fix

Update the OpenAI/DeepSeek provider adapters in Roo Code. When constructing the payload for the /chat/completions endpoint for DeepSeek models, extract any object with "type": "reasoning" from the content array, map its text to a new reasoning_content key at the root of the message object, and leave the remaining text/tool blocks in content.

Extension version: 0.0.8162
VS Code version: Code 1.117.0 (10c8e557c8b9f9ed0a87f61f1c9a44bde731c409, 2026-04-21T16:12:14-07:00)
OS version: Windows_NT x64 10.0.26200
Modes:
Remote OS version: Linux x64 6.6.87.2-microsoft-standard-WSL2

System Info

Item	Value
CPUs	Intel(R) Core(TM) i9-14900HX (32 x 2419)
GPU Status	2d_canvas: enabled GPU0: VENDOR= 0x10de, DEVICE=0x2820 [NVIDIA GeForce RTX 4070 Laptop GPU], DRIVER_VENDOR=NVIDIA, DRIVER_VERSION=32.0.15.9621 ACTIVE GPU1: VENDOR= 0x8086, DEVICE=0xa788 [Intel(R) UHD Graphics], DRIVER_VERSION=32.0.101.6129 GPU2: VENDOR= 0x1414, DEVICE=0x008c [Microsoft Basic Render Driver], DRIVER_VERSION=10.0.26100.8246 Machine model name: Machine model version: direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off trees_in_viz: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	31.71GB (12.15GB free)
Process Argv	--crash-reporter-id 7ec5774c-5de4-4bad-97b6-0f4f6f77491b
Screen Reader	no
VM	0%

Item	Value
Remote	WSL: Ubuntu
OS	Linux x64 6.6.87.2-microsoft-standard-WSL2
CPUs	Intel(R) Core(TM) i9-14900HX (32 x 0)
Memory (System)	15.47GB (9.81GB free)
VM	0%

A/B Experiments

vsliv368cf:30146710
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
pythonrdcb7:31342333
6518g693:31463988
aj953862:31281341
6abeh943:31336334
envsdeactivate2:31464701
cloudbuttont:31379625
3efgi100_wstrepl:31403338
ec5jj548:31422691
cp_cls_t_966_ss:31454198
inlinechat_v2_hd992725:31499106
4je02754:31466945
c3h7c220:31478652
ge8j1254_inline_auto_hint_haiku:31490510
38bie571_auto:31478678
cp_cls_c_1081:31454833
conptydll_true:31498968
ia-use-proxy-models-svc:31452481
e9c30283:31461165
test_treatment2:31471001
46204921:31447328
control_6dc23131:31497324
idci7584:31464702
e3e4d672:31494082
ei9d7968:31496641
534a6447:31496642
hg17d649:31458077
nes-extended-on:31455476
chat:31457767
8hig5102:31480529
89g7j272:31500881
7e187181:31500884
cpptoolson-v2:31475363
i2gc6536:31499202
1g3cj959:31501677
ghj88844:31499326
h08i8180_copy:31475368
23c7c724:31491644
client_tst_t:31495907
ddid_t:31478206
hmra_i5g22:31502055
getcmakediagnosticson:31489824
ja75b849:31495667
nes-perm-reb-0:31490411
pro_large_t:31499376
cp_cls_c_1082:31491634
719di409_sum_t:31499347
nes-cj-aftline:31500937
logging_enabled_new:31498466
j0d79568:31499440
output_3x:31496636
748c7209:31497895
nes-revagr-1:31501785

[roomote-v0]

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

Root Cause

The bug has two related causes depending on the provider path:

Path 1 - DeepSeek native provider (src/api/providers/deepseek.ts): The isThinkingModel check only matches deepseek-reasoner (line 59: modelId.includes("deepseek-reasoner")). When using deepseek-v4-pro or any other model with reasoning enabled, isThinkingModel is false, so mergeToolResultText is not enabled, and the thinking parameter is not sent. The message conversion via convertToR1Format still extracts type: "reasoning" blocks to reasoning_content, but the tool-result merging behavior needed to prevent reasoning loss is missing.

Path 2 - OpenAI compatible provider (src/api/providers/openai.ts): The deepseekReasoner check (line 92) only triggers for deepseek-reasoner or explicit R1 format. For deepseek-v4-pro, the code falls through to convertToOpenAiMessages (src/api/transform/openai-format.ts), which silently drops type: "reasoning" blocks from assistant message content arrays (lines 436-449 only collect text, image, and tool_use types). The reasoning content is completely lost instead of being mapped to reasoning_content at the message top level.

Proposed Fix

1. src/api/transform/openai-format.ts - Add a preserveReasoningContent option to convertToOpenAiMessages. When enabled, extract { type: "reasoning", text: "..." } blocks from assistant message content arrays and map them to a top-level reasoning_content field on the assistant message object.

2. src/api/providers/deepseek.ts - Broaden the thinking model detection: instead of only checking modelId.includes("deepseek-reasoner"), also check if reasoning effort is configured in the options (e.g., modelReasoningEffort is set). This ensures mergeToolResultText and the thinking parameter are enabled for any DeepSeek model with reasoning activated.

3. src/api/providers/openai.ts - When using the OpenAI compatible provider with a model that has reasoning enabled (detected via the reasoning params from getModel()), pass preserveReasoningContent: true to convertToOpenAiMessages. This ensures reasoning content is preserved for DeepSeek and any other OpenAI-compatible provider that returns reasoning_content.

4. Tests - Add test cases for:

   • convertToOpenAiMessages with preserveReasoningContent option
   • DeepSeek handler with non-deepseek-reasoner models that have reasoning enabled
   • OpenAI handler preserving reasoning content for DeepSeek-like models

This approach is backward-compatible (opt-in via option flags) and handles future DeepSeek thinking models without needing model ID hardcoding.

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