DeepSeek thinking mode: reasoning_content must be passed back to API on conversation continuation

[fkyah3]

Bug Report

Description

Using DeepSeek models with thinking mode enabled (thinking: {type: "enabled"}), every API call after the first assistant response fails with:

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

The session becomes stuck — you can't continue the conversation beyond the first assistant reply.

System Info

• OpenCode version: 1.14.19 (running from source, branch anomalyco/opencode)
• OS: Windows 11
• Provider: @ai-sdk/openai-compatible (bundled)
• DeepSeek API: api.deepseek.com, thinking mode enabled

Model Configuration

"deepseek-v4-flash": {
  "limit": { "context": 200000, "output": 393216 },
  "options": { "thinking": { "type": "enabled" } }
}

Also reproduced with deepseek-reasoner (R1) when conversation history contains assistant messages that were stored before thinking mode was enabled.

Steps to Reproduce

1. Configure a DeepSeek V4 model (e.g. deepseek-v4-flash) in opencode.json with thinking: {type: "enabled"} in options
2. Start a new session with this model
3. Send a message — the first assistant reply works fine
4. Send a follow-up message — API returns 400 with the reasoning_content error
5. The session is now stuck; every retry produces the same error

Expected Behavior

Conversation should continue normally across multiple turns when using thinking mode models.

Actual Behavior

Second API call fails with reasoning_content must be passed back. The @ai-sdk/openai-compatible provider's convertToOpenAICompatibleChatMessages() function strips reasoning_content from assistant messages that don't have explicit reasoning parts in their content. On history replay (second turn), these messages lack the reasoning_content field that DeepSeek's API requires for all assistant messages in thinking mode.

Workaround

Add interleaved: { field: "reasoning_content" } to the model config in opencode.json, which causes the existing normalizeMessages() code to inject reasoning_content into providerOptions. But this only partially helps — messages replayed from DB history still get skipped by the narrow condition in normalizeMessages().

Related Issues

• Missing reasoning_content field in the assistant message for DeepSeek API implementation #17523 — same root cause (reasoning_content stripped on replay)
• reasoning_content stripped from assistant messages on replay, causing KV cache invalidation on local inference #19081 — reasoning_content lost during message replay (overlapping fix area)
• The problem with deepseek-reasoner in OpenCode #8934 — general DeepSeek-reasoner compatibility issues

[github-actions]

Thanks for updating the issue! It now follows the contributing guidelines and looks great. We appreciate the clear description, system info, and reproduction steps.

[bilbillm]

Same issue here with deepseek-v4-flash + thinking mode. The error "The reasoning_content in the thinking mode must be passed back to the API" occurs consistently on the second turn — the first assistant reply always succeeds, then every follow-up message fails with a 400 error.

From my investigation, the root cause is:

1. When thinking mode is enabled, DeepSeek API requires ALL assistant messages in the conversation history to include the
   easoning_content field (even if empty string ""), especially when tool calls are involved.
2. The @ai-sdk/openai-compatible provider's convertToOpenAICompatibleChatMessages() function strips
   easoning_content from assistant messages on history replay, so when the second user message is sent, the replayed assistant messages from turn 1 lack the required field.
3. The fix in PR Missing reasoning_content field in the assistant message for DeepSeek API implementation #17523/fix(opencode): Error 400 missing reasoning_content – transform reasoning according to DeepSeek API and aditional test cases #17529 partially addresses this in ProviderTransform.message, but the root issue in the AI SDK message conversion layer may need a separate fix.

A temporary workaround I found: the error doesn't occur if no tool calls are made in the first turn (simple chat-only messages work). But as soon as tool calls happen (file read/write, etc.), the conversation deadlocks.

Hope this gets prioritized — thinking mode is unusable with agent workflows right now.

[fkyah3]

Thanks for confirming — same findings on my end. The tool-call trigger matches what I traced: tool-call messages replayed from history lack
easoning_content\ because the inner condition in
ormalizeMessages()\ (transform.ts) skipped them.

I have a working fix that addresses both the entry condition and the narrow inner skip — committed at \�5b6ad05d\ on branch \ix/permission-reasoning-truncation\ of my fork (\kyah3/opencode-fkyah3). The key changes:

1. Broaden the \hasReasoningContent\ check to fire for any model with \capabilities.reasoning\ (not just models with \interleaved\ configured)
2. Remove the inner condition that filtered by presence of reasoning text / after-last-user / tool-calls — now ALL assistant messages unconditionally get
   easoning_content\ injected (empty string if no reasoning text), including string-content messages from old DB format

So far stable across long conversations with heavy tool use. Hope this helps while a proper upstream fix lands.

[hypernewbie]

same here

[fkyah3]

If you want to try the fix now, it's on my fork branch fix/permission-reasoning-truncation at fkyah3/opencode-fkyah3. Commit b5b6ad05d in packages/opencode/src/provider/transform.ts — removes the narrow condition that skipped history-replayed assistant messages.