Repository navigation
DeepSeek thinking mode: reasoning_content not passed back for tool call turns, causing 400 errors #24722
Description
Description
When using DeepSeek models (e.g. deepseek-v4-pro, deepseek-v4-flash) with thinking mode enabled, the API requires that reasoning_content from assistant messages that contained tool calls be included in all subsequent requests. If it's omitted, the API returns a 400 error.
From DeepSeek's docs:
▎ "For turns that do perform tool calls, the reasoning_content must be fully passed back to the API in all subsequent requests. If your code does not ▎ correctly pass back reasoning_content, the API will return a 400 error."
Reproduction:
- Configure OpenCode to use a DeepSeek model with thinking mode enabled 2. Ask a question that triggers a tool call (e.g. weather lookup, date check, file read)
- The first turn works, but subsequent turns fail with a 400 error
Root cause:
When serializing assistant messages into the conversation context, OpenCode likely drops reasoning_content from the message object. For non-tool-call
turns DeepSeek ignores missing reasoning_content, but for tool call turns it's mandatory.
Expected behavior:
reasoning_content must be preserved in assistant messages that contain tool_calls when sending the conversation history to DeepSeek's API.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon Apr 28, 2026
This issue might be a duplicate of existing issues. Please check:
reasoning_contenterror — same root cause,reasoning_contentnot passed back in thinking modereasoning_contentdropped at API layer causing 400 errors — identical symptom and error messagePlease review these issues and consider closing this one as a duplicate if the problem is already being tracked.
keydexofficial commentedon Apr 28, 2026
karuboniru commentedon Apr 28, 2026
please check this session and related OpenAI API call payload
WhiteGiverMa commentedon Apr 29, 2026
Additional data point from the zen/go proxy (
opencode.ai/zen/go/v1):Confirmed: same bug affects zen/go endpoint
Minimal zen/go reproduction:
Request with mixed
reasoning_content(first assistant has it, second tool_calls does not):{ "model": "deepseek-v4-pro", "messages": [ {"role": "user", "content": "帮我查下文件"}, {"role": "assistant", "content": "好的，我来帮你查。", "reasoning_content": "用户需要查文件，我应该用工具。"}, {"role": "user", "content": "读SOUL.md"}, {"role": "assistant", "content": null, "tool_calls": [{"id":"c1","type":"function","function":{"name":"read","arguments":"{\"path\":\"SOUL.md\"}"}}]}, {"role": "tool", "tool_call_id": "c1", "content": "SOUL内容"}, {"role": "user", "content": "写个总结"} ], "tools": [{"type":"function","function":{"name":"read","description":"read","parameters":{"type":"object","properties":{"path":{"type":"string"}}}}} ], "max_tokens": 20 }→
"Error from provider (DeepSeek): The reasoning_content in the thinking mode must be passed back to the API."Same repro, if ALL assistant messages consistently include
reasoning_content(including the tool_calls message), the request succeeds.Observed behavior
The zen/go proxy sometimes does not return
reasoning_contenton tool_calls responses, creating the inconsistency that triggers the DeepSeek API rejection.Suggested fix for zen/go
Either:
This was originally filed as #25000 (now closed as duplicate).
Patryk676 commentedon May 1, 2026
I can confirm this on my side too.
Environment:
Behavior:
Error:
400 invalid_request_error
"thinking is enabled but reasoning_content is missing in assistant tool call message"
This appears to be the same tool-call history / reasoning_content replay problem. I can reproduce it consistently when the model tries to use tools.
chrispository commentedon May 1, 2026
I have the same error.
Omarchy 3.4.2
OpenCode
Model: Deepseek v4 Pro
Behavior: Normal chat works, after a few messages or tool calls you get: "The
reasoning_contentin the thinking mode must be passed back to the API."I can confirm this closed PR actually fixes it: #24250
I had OpenCode pull the main dev branch and asked it apply the linked fix. Then I re-built, and it's working perfectly for me now. Not sure why that PR got closed.
rekram1-node commentedon May 1, 2026
@chrispository what version of opencode are u on
rekram1-node commentedon May 1, 2026
@Patryk676 your issue doesnt have to do w/ opencode
chrispository commentedon May 1, 2026
1.3.13. looks like i'm a bit behind, so maybe ignore me.
jc01rho commentedon May 4, 2026
Sometimes kimi 2.6 in go also print same errors
lightrao commentedon May 23, 2026
Additional repro context from a real agent workflow:
This was not a simple chat-only turn. The failure happened during a multi-step coding session where the model was:
git statusandgit diff --statThe session continued normally through reasoning and tool-use planning, then failed on the next provider request with:
RequestExecutor.execute: Provider request failed with HTTP 400: {"error":{"message":"Error from provider (DeepSeek): The `reasoning_content` in the thinking mode must be passed back to the API.","type":"invalid_request_error","param":null,"code":"invalid_request_error"}}Environment:
opencode-godeepseek-v4-proThis seems consistent with assistant/tool-call history being replayed without the required
reasoning_contentduring a real multi-step agent flow.lightrao commentedon May 23, 2026
Additional comparison point:
The same model works for me through OpenRouter, but fails through
opencode-go.Comparison:
openrouter + deepseek-v4-pro: works normallyopencode-go + deepseek-v4-pro: fails withreasoning_contenterrors during multi-step / tool-call continuationThat makes it look less like a model-level DeepSeek issue and more like a provider/path-specific replay or normalization problem on the
opencode-goroute.bilal-karagoz commentedon May 25, 2026
Is there any progress on resolution? Or is there any workaround available? I tried reinstalling opencode but no luck
Hisir0909 commentedon May 26, 2026
@bilal-karagoz @lightrao
你们的opencode 版本是？ 如何配置 deepseek 模型的使用的？ opencode现在对 Deepseek provider下的deepseek-v4模型是支持思维链回传的
What is your version of OpenCode? How do you configure the use of the Deepseek model? OpenCode now supports backhaul of the Chain of Thought for the deepseek-v4 model under the Deepseek provider
devcxl commentedon May 27, 2026
官方api是没有这个问题的，应该是opencode-go的模型配置出了问题
The official API does not have this problem; it's likely an issue with the opencode-go model configuration.
Hisir0909 commentedon May 28, 2026
Deepseek api也是有这个问题的(https://api-docs.deepseek.com/zh-cn/guides/thinking_mode#:~:text=%E8%8B%A5%E6%82%A8%E7%9A%84%E4%BB%A3%E7%A0%81%E4%B8%AD%E6%9C%AA%E6%AD%A3%E7%A1%AE%E5%9B%9E%E4%BC%A0%20reasoning_content%EF%BC%8CAPI%20%E4%BC%9A%E8%BF%94%E5%9B%9E%20400%20%E6%8A%A5%E9%94%99) , tool_call中必须回传 思维链, opencode go的上游就是deepseek 官方. opencode 已经支持回传思维链 v1.14.29 请更新opencode版本, 或者请移除你自定义的provider 一些model配置
Deepseek API also has this issue ( https://api-docs.deepseek.com/guides/thinking_mode#:~:text=the%20API%20will%20return%20a%20400%20error.) In tool_call, you must return the chain of thought; the upstream of OpenCode Go is the official DeepSeek. Please update the OpenCode version, or remove some model configurations from your custom provider
devcxl commentedon May 29, 2026
我在升级了 1.15.11 后这些问题似乎都消失了 我原本使用的是1.15.10
These problems seem to have disappeared after I upgraded to 1.15.11. I was originally using 1.15.10
kingpro1985 commentedon May 29, 2026
I saw this while looking at custom model/provider setup issues: "DeepSeek thinking mode: reasoning_content not passed back for tool call turns, causing ...".
If it helps your testing, CloudGPU exposes a hosted OpenAI-compatible endpoint that can route to GPT, Claude, Gemini, DeepSeek, Kimi and GLM behind one API key.
Base URL: https://gpuapis.com/api/v1
Setup guide: https://gpuapis.com/use-cases/deepseek-gemini-claude-api/
I can share a small test key/credit and a cURL request if you want to verify it in your current client before doing any integration work.
github-actions commentedon Jul 29, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.