Bug: DeepSeek reasoning_content not passed back in multi-turn conversations

Description

Bug: DeepSeek `reasoning_content` not passed back in multi-turn conversations

Affected provider: DeepSeek (via OpenRouter or DeepSeek API directly)
Affected models: DeepSeek V4 Pro (and any DeepSeek model with thinking mode enabled)

Description

When using a DeepSeek model with thinking mode enabled, the API requires that reasoning_content blocks returned in assistant messages are passed back as-is in subsequent turns. OpenCode currently does not preserve these blocks when building the conversation history, causing the following error on the second message:

[DeepSeek] The `reasoning_content` in the thinking mode must be passed back to the API.

Steps to Reproduce

Configure OpenCode with DeepSeek V4 Pro via OpenRouter (openrouter/deepseek/deepseek-v4-pro) or DeepSeek API directly
Enable thinking mode (or use a model where it is on by default)
Send a first message — response succeeds
Send a second message in the same session
Error is thrown immediately

Expected Behavior

OpenCode should preserve the reasoning_content block from assistant messages and include it verbatim when building the messages array for subsequent API calls.

Expected assistant message format in history:

{
  "role": "assistant",
  "content": [
    {
      "type": "reasoning_content",
      "reasoning_content": "<content returned by the model>"
    },
    {
      "type": "text",
      "text": "<actual response>"
    }
  ]
}

Actual Behavior

The reasoning_content block is stripped from the assistant message before the next API call, causing DeepSeek to reject the request.

Environment

OpenCode version: v1.14.24
OS: MacOs
Provider: DeepSeek via OpenRouter
Model: deepseek/deepseek-v4-pro

References

DeepSeek API docs – Thinking mode
DeepSeek explicitly states: "The reasoning_content in the thinking mode must be passed back to the API"

Workaround

Disable thinking mode for DeepSeek models in OpenCode settings. This avoids the error but reduces model performance.

Terminal

No response

This issue might be a duplicate of existing issues. Please check:

[DeepSeek V4] reasoning_content not round-tripped — 400 error on multi-turn tool calls #24190: Same bug — reasoning_content not round-tripped on multi-turn conversations with DeepSeek V4, same error message, same root cause, already assigned and being worked on.

Please add a "+1" or your additional context to the existing issue instead.

+1

In trying out deepseek v4, I was originally getting nonspecific AI_APICallError(s) when adding queries after the first response... In researching it here, I then saw multiple reports of outstanding errors along these lines (such as the above), but then saw that opencode 1.14.24 claimed to fix such... after downloading it, I was able to submit a ~handful of queries before it again is now responding " 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"}}"...
[FWIW, I think that my 'provider' for deepseek v4 is configured to use the claude api, as their web site currently recommends...]

same issue

+1

This is not an isolated issue — it's a systemic compatibility problem affecting multiple open-source projects using DeepSeek V4 thinking mode + tool calls. Same root cause, same error across all of them.

Known affected projects (as of April 26):

Project	Issue
OpenCode	#24104 #24130 #24261
OpenClaw	openclaw#71160 openclaw#71455
n8n	n8n#29119
Continue.dev	continuedev#10758
HuggingFace Chat-UI	chat-ui#1664

Root cause: AI SDKs (@ai-sdk/openai-compatible, OpenRouter gateway) don't preserve reasoning_content on assistant messages with tool_calls across turns. DeepSeek V4 thinking mode requires it on every assistant message after a tool call — including empty strings.

Fix direction (verified across projects): Unconditionally inject reasoning_content: "" for all assistant messages before API dispatch. Our fork (fkyah3/opencode-fkyah3, commit b5b6ad05d) implements this at the normalizeMessages() level. OpenClaw implemented a similar approach in #71105.

This is not a config issue on your side — you don't need to switch providers or models.

Sorry for delay yall, was traveling but have a PR that I validated should behave as expected w/ openrouter now, contains a small code change and a bump to openrouter sdk package that we use, I talked w/ openrouter team and they made this patch specifically due to us raising the issue.

Will release soon

I have no idea why this has been marked 'closed' as it still appears to be happening in 1.14.29 said to have been built yesterday

@DXXS

@DXXS tell me more info please, what provider are you using? Is it openrouter? If it's not openrouter then maybe open a new issue?

Is it a custom provider?

?? 'DeepSeek API directly' as shown in issue title. In my "~/.config/opencode/opencode.json" (before the build reportedly may now include it?), I had added:

"deepseek": {
  "npm": "@ai-sdk/anthropic",
  "name": "DeepSeek",
  "options": {
    "baseURL": "https://api.deepseek.com/anthropic",
    "apiKey": "{env:DEEPSEEK_API_KEY}"
  },
  "models": {
    "deepseek-v4-pro": {
      "name": "DeepSeek-V4-Pro",
      "limit": {
        "context": 1048576,
        "output": 262144
      },
      "options": {
        "reasoningEffort": "max",
        "thinking": {
          "type": "enabled",
          "budgetTokens": 8192
        }
      }
    }
  }
}

Navigation Menu

Repository navigation

Bug: DeepSeek reasoning_content not passed back in multi-turn conversations #24261

Description