Repository navigation
Support non-thinking mode for DeepSeek V4 Flash in Provider API #697
Description
Feature Description
Please add support for disabling reasoning / thinking when using deepseek/deepseek-v4-flash through the CommandCode Provider API.
DeepSeek V4 Flash natively supports both thinking and non-thinking modes, but I currently cannot find a way to enable non-thinking mode through:
POST /provider/v1/chat/completions
Using:
{ "reasoning_effort": "none" }returns HTTP 400:
Invalid option: expected one of "low"|"medium"|"high"|"xhigh"|"max"
Using DeepSeek's native parameter:
{ "thinking": { "type": "disabled" } }succeeds, but the model still performs reasoning and reports reasoning tokens, so the parameter appears to be ignored or not forwarded upstream.
Please expose a true non-thinking option for models that support it natively. Any of these API shapes would work:
{ "reasoning_effort": "none" }{ "thinking": { "type": "disabled" } }- A CommandCode-specific option such as
{ "reasoning_effort": "off" }
The important part is that DeepSeek V4 Flash actually runs in native non-thinking mode and produces no reasoning tokens.
Use Case
I use DeepSeek V4 Flash for simple workloads where reasoning is unnecessary, including:
- Translation
- Text rewriting
- Classification
- Information extraction
- Formatting
- Simple structured-output tasks
For these workloads, reasoning adds unnecessary latency and token usage without improving the result.
For example, I use the CommandCode Provider API as the backend for a translation model. Translation requests are usually straightforward and should return translated text directly, but DeepSeek V4 Flash currently spends reasoning tokens before producing the translation.
Being able to disable thinking would make the model significantly more suitable for latency-sensitive and high-volume workloads.
Additional Context
Endpoint
https://api.commandcode.ai/provider/v1/chat/completions
Model
deepseek/deepseek-v4-flash
Reproduction 1
Request:
{
"model": "deepseek/deepseek-v4-flash",
"messages": [
{
"role": "user",
"content": "Translate this text directly."
}
],
"reasoning_effort": "none"
}Response:
{
"error": {
"message": "Invalid option: expected one of \"low\"|\"medium\"|\"high\"|\"xhigh\"|\"max\"",
"type": "invalid_request_error",
"param": "reasoning_effort"
}
}Reproduction 2
Request:
{
"model": "deepseek/deepseek-v4-flash",
"messages": [
{
"role": "user",
"content": "Translate this text directly."
}
],
"thinking": {
"type": "disabled"
}
}The request succeeds, but reasoning tokens are still generated.
DeepSeek's native API supports switching V4 Flash between thinking and non-thinking modes, so it would be helpful if the CommandCode Provider API exposed the same capability.
How important is this to you?
Important for my workflow
Activity
vipulgupta2048 commentedon Aug 18, 2026
Thanks for the feedback, @cr-zhichen will add this to the roadmap. Some models will by default have a thinking level set. So, even if you send none for thinking, it will still be processing thinking tokens.
Hangsiin commentedon Aug 22, 2026
Yeah, please fix this issue as soon as possible. I think disabling thinking was possible yesterday, but it's not working again today. It's really annoying. I don't think it should be that difficult of a problem.
ahmadbilaldev commentedon Sep 7, 2026
@cr-zhichen @Hangsiin I have shipped a fix for this one. Please retry and thanks for reporting this.
Hangsiin commentedon Sep 8, 2026
Retested on September 9, 2026, after the fix announcement above. Unfortunately, non-thinking mode still does not work in the Provider API requests tested here.
Environment
https://api.commandcode.ai/provider/v1/chat/completionsdeepseek/deepseek-v4-flash(also confirmed in responsemodel)x-cmd-zdr: 1Minimal reproduction
{ "model": "deepseek/deepseek-v4-flash", "messages": [ { "role": "user", "content": "Translate to Korean. Output only the translation: The meeting starts tomorrow at three in the afternoon." } ], "max_tokens": 256, "thinking": { "type": "disabled" } }Observed HTTP 200, but the response contained both non-empty
message.reasoningand nonzerousage.completion_tokens_details.reasoning_tokens:x-cmd-zdr: 1: 51 reasoning tokens, 66 completion tokens.Both returned a visible Korean translation. This is not merely a missing/ambiguous usage field: reasoning text was present too.
Using
reasoning_effort: "none"or"off"instead still returns HTTP 400:Other tested shapes (
reasoning: {enabled: false},reasoning: {effort: "none"},enable_thinking: false,thinking: false, andthinking: {enabled: false}) also returned reasoning tokens, with and without ZDR.Repeated OFF / low / xhigh comparison
Same prompt and settings within each workload, three independent calls per setting,
max_tokens: 4096, ZDR enabled, non-streaming. OFF meansthinking: {type: "disabled"}; the other settings usereasoning_effortwith nothinkingfield.Each cell below is mean reasoning tokens / mean end-to-end request seconds:
value: 37,label: "control")Compute 987654321 * 123456789. Output only the exact integer answer.All 9 OFF-requested calls returned nonzero reasoning tokens and non-empty reasoning text. All 27 comparison calls returned HTTP 200. For the arithmetic workload, one call in each setting hit the 4096-token cap with no visible answer; the other two returned the correct integer. The capped samples and small sample size mean this is not a general performance ranking of low versus xhigh.
Could you please confirm:
/provider/v1/chat/completionsfor this exact model, including both ZDR and default upstream routing?thinking.type: "disabled"request is still intended to work?Related: #776 remains open, and the later comment in #726 says the ability to turn off reasoning is being added. Clarifying whether non-thinking support has shipped separately from the reasoning echo-back fix would help.
Only synthetic test prompts and aggregate measurements are included here; no credentials or private application data.