Repository navigation
Closed
Labels
bugSomething isn't workingSomething isn't workingcoreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)
Description
Description
Description
When using the newly released DeepSeek V4 Flash model (deepseek-v4-flash) for file writing operations, the following error occurs:
The reasoning_content in the thinking mode must be passed back to the API.
Background
DeepSeek released V4 preview today (see: https://mp.weixin.qq.com/s/8bxXqS2R8Fx5-1TLDBiEDg), with two models:
deepseek-v4-prodeepseek-v4-flash
The official announcement explicitly states that V4 is optimized for Agent products including Claude Code, OpenCode, CodeBuddy, etc. Both models support thinking mode, configurable viareasoning_effortparameter (high/max).
Root Cause
DeepSeek Thinking Mode API requires:
- When thinking mode is enabled, assistant messages must contain a
reasoning_contentfield - For tool call scenarios,
reasoning_contentmust be passed back to the API in all subsequent requests - Reference: https://api-docs.deepseek.com/guides/thinking_mode#tool-calls
The known solution in OpenCode is to configureinterleaved:
"interleaved": {
"field": "reasoning_content"
}
Issue
1. New model names (deepseek-v4-flash, deepseek-v4-pro) are not pre-configured with interleaved in the default provider settings
2. Users must manually add this configuration for proper functioning
3. Compared to legacy model deepseek-reasoner, V4's default behavior may differ (per official docs: deepseek-chat temporarily points to deepseek-v4-flash non-thinking mode, but this may change over time)
Suggested Fix
1. Update default provider configuration: Pre-configure interleaved for deepseek-v4-pro and deepseek-v4-flash models
2. Or auto-detect: Automatically handle reasoning_content when DeepSeek models with thinking mode are detected
Workaround
Users can manually configure in opencode.json:
{
"provider": {
"deepseek": {
"npm": "@ai-sdk/openai-compatible",
"name": "DeepSeek",
"options": {
"baseURL": "https://api.deepseek.com/v1",
"apiKey": "{env:DEEPSEEK_API_KEY}"
},
"models": {
"deepseek-v4-flash": {
"name": "DeepSeek V4 Flash",
"interleaved": {
"field": "reasoning_content"
}
},
"deepseek-v4-pro": {
"name": "DeepSeek V4 Pro",
"interleaved": {
"field": "reasoning_content"
}
}
}
}
}
}
Notes on interleaved Configuration
Based on prior issues (#6040, #8934), configuring "interleaved": { "field": "reasoning_content" } for DeepSeek models using the official API (@ai-sdk/openai-compatible) has minimal side effects:
- Slightly increased token usage (DeepSeek API ignores reasoning_content from prior turns per #5577, but still bills for them)
- Slightly increased network bandwidth
This is the recommended configuration per DeepSeek's API documentation.
Related Issues
This issue type has been reported multiple times, but is new for V4 models:
- #4947, #5027, #5332, #5577, #6040, #8934, #10788, #17523
OpenCode Version
1.14.22
Operating System
ubuntu 22.04
### Plugins
rtk
### OpenCode version
1.14.22
### Steps to reproduce
_No response_
### Screenshot and/or share link
_No response_
### Operating System
Ubuntu 22.04
### Terminal
_No response_Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingcoreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)
Activity
github-actions commentedon Apr 24, 2026
This issue might be a duplicate of existing issues. Please check:
deepseek-v4-promodel ID is not recognized as a thinking model, causingreasoning_contenterrors even withinterleavedconfigured #24097:deepseek-v4-promodel ID not recognized as thinking model, causing identicalreasoning_contenterrorsThere appear to be several issues open today covering the same DeepSeek V4
reasoning_content/interleavedconfiguration problem. Please coordinate with the reporters of those issues, and consider closing as a duplicate if the underlying problem is the same.fkyah3 commentedon Apr 25, 2026
Same issue affecting multiple projects — updated list as of April 26:
All share the same root cause: AI SDKs don't preserve reasoning_content on assistant messages with tool_calls across multi-turn agent conversations. Our fork (fkyah3/opencode-fkyah3) implements a brute-force fix at the normalizeMessages() level: unconditionally inject reasoning_content: "" for ALL assistant messages before API dispatch. Verified working with direct DeepSeek API.
See #24261 for more context. Not a config issue — just ecosystem adaptation lag.