Repository navigation
Console Go relay: HTTP 400 (empty body) when request combines reasoning_content echo-back with reasoning_effort on deepseek-v4-flash #48180
Description
Summary
POST https://opencode.ai/zen/go/v1/chat/completions with model=deepseek-v4-flash rejects requests that contain BOTH:
reasoning_contentecho-back on historical assistant messages (required by DeepSeek-family thinking models when replaying tool-call turns), AND- any
reasoning_effortvalue (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.
Activity
github-actions commentedon Sep 9, 2026
This issue might be a duplicate of existing issues. Please check:
opencode.ai/zen/go/v1/chat/completions), same model (deepseek-v4-flash), same HTTP 400 with opaque{"object":"error","model":"deepseek-v4-flash"}body, and the same root hypothesis — multi-turn sessions withreasoning_contentecho-back on historical assistant messages hitting a relay-layer rejection.VPpexis commentedon Sep 28, 2026
Still reproducing on the renamed id
deepseek-v4.1-flash(observed 2026-09-27/28), through a codex-router v0.6.0 hop.Observed over two days: 12 failures out of 379 requests (~3%), all on
deepseek-v4.1-flash;deepseek-v4-prorouted through the same edge never failed. Each failure aborts a long Codex turn with no recovery.Edge response (via the OpenAI SDK): HTTP 400 with a bare body —
{"model": "deepseek-v4.1-flash"}, nomessagefield, same empty-error shape as the original report.Shape that trips it: long tool-call histories where historical assistant tool-call turns carry echoed
reasoning_contentand the request setsreasoning_effort(highandlowboth seen). Matches the bisect above: removing either side returns 200. Short synthetic replays of the same combination sometimes pass, which makes us suspect uneven edge replicas/rollout rather than a pure payload rule — over long sessions it was effectively deterministic.Happy to provide a captured request body (scrubbed) if useful.
Alegria28 commentedon Oct 6, 2026
I've had the same problem with DeepSeek V4.1 Flash during long conversations after multiple auto or manual
/compactcommands. At some point I start gettingError: Bad Request: {"model":"deepseek-v4.1-flash"}when I get closer to the context limit.What I've done to make it work again (because once I get the error I can't continue the conversation) is to change the current model (to GPT 5.6 Luna for example) and then
/compact. This way I can change the model to DeepSeek V4.1 Flash again and continue the same conversation. At first I thought this error occurred because of usage limits but it didn't make sense because I checked my dashboard and the limits weren't reached. I don't have access to the machine where this happened right now, but I can provide the OpenCode version and other environment information later if needed.I'm happy to test a fix, provide more information if I can reproduce it again or help fix this problem if needed.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed bisect. I couldn't reproduce this here because it needs a real OpenCode Go key, so a maintainer with Go access will need to look at it.
One thing I noticed: without credentials, the Go endpoint now answers
model: deepseek-v4-flashwith HTTP 410ModelDeprecated("Model deepseek-v4-flash has been deprecated."). That suggests the model may have been retired on the relay since you reported this. I couldn't check whether that's also what subscribers get. If you still have access, could you replay your captured body once more and say whether you now get the empty 400 or a 410? If you have the minimal repro script you mentioned, please post it with any keys or session IDs removed.