Featured image of post DeepSeek + Claude Code: Thinking Block Compatibility Analysis

DeepSeek + Claude Code: Thinking Block Compatibility Analysis

Analysis of the root cause of 400 errors triggered in multi-turn conversations when Claude Code uses DeepSeek models in extended thinking mode, comparison with OpenCode's handling approach, and community solutions.

语速

Problem Description

When using DeepSeek models (such as deepseek-v4-flash) directly in Claude Code with extended thinking enabled, multi-turn conversations trigger a 400 error:

1
Bad Request: {"error":{"message":"The content[].thinking in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}

Root Cause Analysis

Call Chain

1
Claude Code → DeepSeek Anthropic Compatible Endpoint (https://api.deepseek.com/anthropic)

Protocol Incompatibility

According to the DeepSeek Anthropic API Compatibility Documentation, the compatibility status is as follows:

Message FieldSupport Status
content[].thinking✅ Supported
content[].redacted_thinking❌ Not Supported

In extended thinking mode during multi-turn conversations, Claude Code faithfully passes back all thinking blocks from the previous round (including redacted_thinking types) to the API as-is. DeepSeek does not recognize redacted_thinking, hence the 400 error.

Additionally, DeepSeek’s thinking block format differs from Anthropic’s native protocol, and the replay logic in tool_use scenarios is not fully compatible either.

Core Conflict

  • Anthropic API requirement: In extended thinking mode, content[].thinking and content[].redacted_thinking must be passed back unchanged
  • DeepSeek compatibility layer: Only supports thinking, does not support redacted_thinking
  • Claude Code behavior: Hard-coded according to Anthropic protocol, does not distinguish between target endpoint types

Community Feedback

This is a widespread community issue that almost all CC agent/router projects have encountered:

IssueProjectTitle
#1cc-useDeepSeek Thinking Mode Error: content[].thinking Must Be Passed Back
#878openclaudeDeepSeek V4: reasoning_content must be passed back (400) on tool_calls
#1355claude-code-routerCCR 代理 deepseek V4 思考时返回 400
#4543new-apiClaudeCode 接入 DeepSeek V4 遇到 400 reasoning_content 报错
#3559routerDeepSeek API Error 400 – Missing reasoning_content
#16748hermes-agentDeepSeek /anthropic: stripped thinking blocks cause HTTP 400 on replay
#2414cc-switchClaude 使用 cc-switch 配置 deepseek-v4-pro,无法识别字段
#174cc-haha/compact 命令在使用 DeepSeek API 时无法工作

DeepSeek Official Response

Zero response. Nor is there any need to respond.

  • First, DeepSeek has no public API issue repository. All feedback occurs in third-party projects without any DeepSeek official personnel participating in any discussions.
  • Second, whether to use Anthropic as a compatibility standard, I think DeepSeek should be hesitant.

Temporary Workarounds

  1. Disable extended thinking — When using DeepSeek in CC, turn off thinking mode
  2. Use proxy filtering — Add a proxy layer between CC and DeepSeek to filter out redacted_thinking blocks
  3. Switch models — Use DeepSeek for non-thinking scenarios and Anthropic native models for thinking scenarios

Why Doesn’t OpenCode Have This Problem?

OpenCode (opencode-ai/opencode) naturally avoids this problem architecturally, not through a dedicated “fix”.

The key lies in the convertMessages method in internal/llm/provider/anthropic.go (lines 60-119):

  • When building assistant messages, it only passes back TextContent (text) and ToolCall (tool calls)
  • Completely ignores ReasoningContent (thinking content), not putting it in messages
  • thinking content is only displayed in the UI through stream thinking_delta events and is not passed back to the API

Comparison with Claude Code’s behavior:

Claude CodeOpenCode
thinking replay✅ Faithfully replay all thinking blocks (including redacted_thinking)❌ Do not replay thinking blocks
architectural reasonFollow Anthropic API specification, requires unchanged replaySelf-managed conversation state, thinking only for UI display
DeepSeek compatibility❌ Triggers 400 (redacted_thinking not recognized)✅ Not affected (doesn’t pass thinking at all)

Conclusion: OpenCode avoids the problem at the cost of not following Anthropic’s extended thinking specification. This approach is friendly to third-party compatible endpoints like DeepSeek, but if Anthropic native thinking context retention capability is needed in the future, re-implementation may be necessary.

Does Not Replay Thinking Blocks Affect DeepSeek Performance?

Basically no, reasons:

  1. thinking blocks are the model’s internal scratchpad, not final output. The text replies and tool calls in the conversation history already retain key decisions and conclusions
  2. DeepSeek’s reasoning is closer to OpenAI’s mode — each round is generated independently, unlike Anthropic’s strong reliance on cross-round replay to maintain reasoning coherence
  3. OpenCode’s extensive actual use also confirms this — community users run multi-turn conversations using DeepSeek thinking mode in OpenCode without feedback about reasoning quality degradation

The truly potentially affected extreme scenario: in ultra-long multi-turn tasks, the model may repeat conclusions it has already reasoned through. However, in most actual use, the impact is negligible.

CC itself has similar thinking block replay bugs on Anthropic models (not DeepSeek-specific):

IssueTitleStatus
#10199API Error 400 - Thinking Block Modification ErrorOpen (oncall)
#51985thinking block missing in multi-turn conversationsOpen
#20692thinking blocks order error on first tool useOpen (oncall)
#54482Thinking blocks stripped from context every turn (Opus 4.7)Open