BUG: DeepSeek API 400 error — reasoning_content in thinking mode must be passed back

[fyc09]

What happened?

When using Qwen Code with DeepSeek's API (deepseek-v4-flash model, base URL https://api.deepseek.com/v1), the following error occurs intermittently during conversation:

✕ [API Error: 400 The reasoning_content in the thinking mode must be passed back to the API.]

This happens when DeepSeek's reasoning model returns a reasoning_content field in its response, and Qwen Code fails to pass it back in subsequent API requests. DeepSeek's API requires that reasoning_content from the assistant's response be included in the messages array for follow-up requests when thinking mode is active.

What did you expect to happen?

The conversation should continue normally without API errors. Qwen Code should properly preserve and pass back the reasoning_content field from the assistant's response when making subsequent API calls to DeepSeek's API.

Client information

Client Information

``` Qwen Code 0.15.1 (9010c09) 运行环境 Node.js v22.18.0 / npm 11.10.0 IDE 客户端 VS Code 操作系统 win32 x64 (10.0.26200) 认证 API Key - openai 基础 URL https://api.deepseek.com/v1 模型 deepseek-v4-flash 快速模型 deepseek-v4-flash 沙箱 no sandbox 代理 no proxy 内存使用 261.1 MB ```

Login information

Using API Key authentication with OpenAI-compatible provider pointing to DeepSeek API:

• Provider type: openai
• Base URL: https://api.deepseek.com/v1
• Model ID: deepseek-v4-flash (custom provider config)

Anything else we need to know?

• Platform: Windows 11 (win32 x64, build 26200)
• VS Code as IDE client
• Approval mode: yolo
• The issue is likely caused by Qwen Code's OpenAI-compatible API adapter not handling DeepSeek's proprietary reasoning_content field, which is part of DeepSeek's thinking/reasoning mode response format.
• Other reasoning models with similar 'thinking' modes (e.g., DeepSeek R1, Kimi K2.5) may also be affected.
• This is similar in nature to issue /bug /bug Kimi-K2.5 模型调用技能报错 ✕ [API Error: The parameter messages.tool_calls.type specified in the request are not valid: invalid value: , value must be function. Request id: 0217769279314770076f3f588c303a7ab8265369cf815762b3fbd #3553 (Kimi K2.5 API error with tool_calls), but with a different error message and root cause.

[pomelo-nwu]

@fyc09 Check if ~/.qwen/settings.json is correct. I just connected to DeepSeek and built a small feature

  "openai": [ {
        "id": "deepseek-v4-pro",
        "name": "deepseek-v4-pro",
        "baseUrl": "https://api.deepseek.com",
        "envKey": "DEEPSEEK_API_KEY",
        "generationConfig": {
          "extra_body": {
            "enable_thinking": true,
            "reasoning_effort": "high"
          }
        }
      }
]

[fyc09]

That's not working. It seems that the bug occurs only after exiting qwen code and then resume the session. It also randomly occurs during long tasks.

@fyc09 Check if ~/.qwen/settings.json is correct. I just connected to DeepSeek and built a small feature

"openai": [ {
"id": "deepseek-v4-pro",
"name": "deepseek-v4-pro",
"baseUrl": "https://api.deepseek.com",
"envKey": "DEEPSEEK_API_KEY",
"generationConfig": {
"extra_body": {
"enable_thinking": true,
"reasoning_effort": "high"
}
}
}
]

[fyc09]

Root cause analysis and fix

I did a deep dive into this bug. There are two independent causes, both need to be fixed:

Cause 1: Session resume strips reasoning_content

When exiting Qwen Code and resuming a session, buildApiHistoryFromConversation() in sessionService.ts calls stripThoughtsFromHistory() by default (before building the API request). This removes all thought parts (which carry
reasoning_content) from the history before sending to the API. This explains why the error occurs immediately after resuming a session.

Fix: Changed the default of stripThoughtsFromHistory from true to false. Thought parts are now preserved by default on resume.

Cause 2: Active session idle cleanup strips old reasoning_content

client.ts has a thinkingClearLatched mechanism: after the conversation is idle for > 5 minutes (aligned with provider prompt-cache TTL), a sticky latch is permanently enabled, and on every subsequent user message, it calls
stripThoughtsFromHistoryKeepRecent(1), keeping only the most recent turn's thought block. This explains the intermittent errors during long tasks—when the user pauses briefly and then continues, the idle timer triggers the latch, and old
reasoning_content is silently removed, causing DeepSeek to return 400 when those messages are passed back.

Fix: Removed the thinkingClearLatched mechanism entirely.

⚠️ Trade-off question

Removing the latch means reasoning_content from all prior turns will accumulate in the conversation history indefinitely. The latch was originally designed to save tokens for other reasoning models (e.g., OpenAI o-series where the
reasoning field is optional and doesn't need to be passed back).

Three approaches:

A. Keep the fix as-is — remove the latch, accept token bloat for all reasoning models. Simple and correct.

B. Make stripping provider-aware — track which provider generated the reasoning_content, only strip for providers that allow it. More complex but targeted.

C. Add a user-configurable option — e.g. "stripThoughtsOnIdle": true/false in settings.json, defaulting to false (safe for DeepSeek). Users who want token savings can opt in, but they'd need to know their provider's requirements.

Which approach do you prefer? Or is the token bloat from old thinking blocks negligible enough that A is fine?

[tanzhenxin]

@fyc09 Thanks for the thorough root-cause analysis — both causes are exactly right, and this matches what we've been seeing internally.

On the trade-off question: we'd lean toward approach A for now. Keeping the latch (or a variant) adds subtle, provider-specific behavior that's hard to reason about, and the silent stripping is precisely what caused this bug. Removing it trades a small amount of token bloat for lossless, predictable history — which is the right default for a correctness-sensitive path like session resume. If token bloat turns out to be a real pain for o-series style providers later, we can revisit with a provider-aware strategy (B) rather than a user-facing flag (C).

Would you like to open a PR with the two fixes?

1. sessionService.ts — flip stripThoughtsFromHistory default to false in buildApiHistoryFromConversation.
2. client.ts — remove the thinkingClearLatched mechanism (field, reset in resetChat, and the idle-cleanup block that calls stripThoughtsFromHistoryKeepRecent(1)), along with the now-unused clearContextOnIdle.thinkingThresholdMinutes setting plumbing.

Happy to review once it's up. Thanks again for digging into this!

[fyc09]

Reopen: clarify conflict between #3579 and #3304

This issue is being reopened to clarify a correctness conflict introduced while fixing #3579.

Context

• Bug: Switching models mid-session causes API failures. #3304 fixed cross-provider/model-switch failures by stripping thought blocks on model switch.
• BUG: DeepSeek API 400 error — reasoning_content in thinking mode must be passed back #3579 requires preserving reasoning_content for DeepSeek thinking mode, otherwise DeepSeek returns 400 (The reasoning_content in the thinking mode must be passed back to the API.).

Current conflict

To satisfy #3579, preserving reasoning-related content can make the regression test from #3304 fail (or require changing its expected behavior), because #3304 previously enforced stripping thoughts on model switch.

So we currently have a conflict between:

1. Compatibility/correctness for strict OpenAI-compatible providers after model switch (Bug: Switching models mid-session causes API failures. #3304 path), and
2. Compatibility/correctness for DeepSeek thinking mode requiring reasoning continuity (BUG: DeepSeek API 400 error — reasoning_content in thinking mode must be passed back #3579 path).

Clarification requested

Please confirm the intended product/compatibility policy:

1. Should we keep Bug: Switching models mid-session causes API failures. #3304 behavior as a hard guarantee (strip on model switch), and solve BUG: DeepSeek API 400 error — reasoning_content in thinking mode must be passed back #3579 only via resume/idle-path fixes?
2. Or should we replace Bug: Switching models mid-session causes API failures. #3304's strip-on-switch behavior with provider-aware outbound sanitization, so strict providers are protected while DeepSeek keeps required reasoning_content?
3. If (2) is preferred, what is the expected source of truth for provider capability (static allowlist, provider metadata, or model-provider config)?

Why reopening

Without a clear decision here, any fix may unintentionally regress either #3304 or #3579.

[fyc09]

@tanzhenxin @pomelo-nwu Could you please manually reopen this issue? I do not have permission to run reopenIssue, and we need maintainers' decision here because there is an explicit conflict between #3579 and #3304 behavior.

[wenshao]

Reopened per @fyc09's 4-25 clarification request — sorry for the delay.

Adding one more residual call site on top of the #3304-vs-#3579 conflict you raised, which I found while triaging #3619 (DeepSeek 400 still being reported on 0.15.3):

Missed path: load_history in slashCommandProcessor.ts:646

case 'load_history': {
  config?.getGeminiClient()?.setHistory(result.clientHistory);
  config?.getGeminiClient()?.stripThoughtsFromHistory();  // ← strips reasoning right after restoring history
  ...
}

PR #3590 flipped the default in buildApiHistoryFromConversation, but the /chat resume path goes through setHistory + an explicit stripThoughtsFromHistory() call here, which still drops all reasoning_content immediately after restoring. This matches the symptom users in #3619 keep reporting ("error appears right after resuming a session").

So the residual surface in main right now is:

1. load_history (slashCommandProcessor.ts:646) — explicit strip call, not covered by fix(core): preserve reasoning_content during session resume and active sessions (GH#3579) #3590; this is new on top of your earlier scope and looks safe to fix independently
2. Model switch (config.ts:1427) — the Bug: Switching models mid-session causes API failures. #3304 design path that's the core of your earlier conflict question
3. Rewind (AppContainer.tsx:1710) — /rewind and double-ESC

(2) and (3) still need a maintainer decision on your three clarification questions before we can land a clean fix. (1) is independent of that decision and could be addressed first as a quick follow-up to #3590.

@tanzhenxin pinging for the policy call on (2)/(3) given the #3304 history.