Summary
POST https://opencode.ai/zen/go/v1/chat/completions with model=deepseek-v4-flash rejects requests that contain BOTH:
reasoning_content echo-back on historical assistant messages (required by DeepSeek-family thinking models when replaying tool-call turns), AND- any
reasoning_effort value (low/medium/high)
The response is HTTP 400 with an empty error body:
{"object":"error","model":"deepseek-v4-flash"}
No message field, so it is impossible to tell what failed. For agents this is fatal: a long session with many tool calls hits this deterministically at some point and cannot recover.
Repro (bisect by replaying a captured request body)
Captured the failing request body from a real session and replayed it with the same x-opencode-session header:
| Variant |
Result |
| Original body (24 assistant msgs with reasoning_content echo-back + reasoning_effort: high) |
HTTP 400 (same empty body) |
| Remove reasoning_effort |
HTTP 200 |
| Remove reasoning_content echo-back, keep high |
HTTP 200 |
| reasoning_effort: medium / low (full body) |
HTTP 400 |
| Short request + high (no echo-back history) |
HTTP 200 |
So the trigger is the combination, not either field alone. Removing either side restores 200.
Expected
Either accept the combination (it is a valid OpenAI-compatible payload), or return a descriptive error message instead of a bare {"object":"error","model":...}.
I believe this is in the Console Go relay layer (the same endpoint serves other models fine; deepseek-v4-pro with the same combination is not affected per other reports). Happy to provide more details or a minimal repro script.
Summary
POST https://opencode.ai/zen/go/v1/chat/completions with
model=deepseek-v4-flashrejects requests that contain BOTH:reasoning_contentecho-back on historical assistant messages (required by DeepSeek-family thinking models when replaying tool-call turns), ANDreasoning_effortvalue (low/medium/high)The response is
HTTP 400with an empty error body:No message field, so it is impossible to tell what failed. For agents this is fatal: a long session with many tool calls hits this deterministically at some point and cannot recover.
Repro (bisect by replaying a captured request body)
Captured the failing request body from a real session and replayed it with the same
x-opencode-sessionheader:So the trigger is the combination, not either field alone. Removing either side restores 200.
Expected
Either accept the combination (it is a valid OpenAI-compatible payload), or return a descriptive error message instead of a bare
{"object":"error","model":...}.I believe this is in the Console Go relay layer (the same endpoint serves other models fine; deepseek-v4-pro with the same combination is not affected per other reports). Happy to provide more details or a minimal repro script.