Repository navigation
deepseek-v4-pro on opencode-go /responses fails on any multi-turn request (flash & official API both work) #42135
Description
Env: Windows 11, Codex with wire_api = responses via cc-switch → https://opencode.ai/zen/go/v1, model deepseek-v4-pro. I retried right after the 0813 model update and the problem is still there.
What happens: First turn in a fresh conversation is fine. From the second turn on, as soon as the request includes the previous assistant reply, it returns 400.
Errors I've seen (two variants):
Error from provider (Console Go): Upstream request failed: [invalid_request_error] Invalid assistant message: content or tool_calls must be set
and earlier:
Failed to deserialize the JSON body into the target type: messages[4]: missing field `id` at line 1 column ...
Same request with deepseek-v4-flash returns 200, and going straight to the official DeepSeek API (api.deepseek.com/v1/responses) also returns 200. So it looks like Console Go's conversion from Responses to its internal messages format doesn't handle pro's assistant message history properly.
Minimal repro (same body, pro → 400 / flash → 200):
curl -s https://opencode.ai/zen/go/v1/responses \
-H "Authorization: Bearer $KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-pro",
"input": [
{"type":"message","role":"user","content":[{"type":"input_text","text":"hi"}]},
{"type":"message","role":"assistant","content":[{"type":"output_text","text":"hello"}]},
{"type":"message","role":"user","content":[{"type":"input_text","text":"how are you?"}]}
]
}'Swap model to deepseek-v4-flash with the exact same body and it returns 200.
This seems related to #42090, #42091 and #36354 — Console Go validates pro's message/tool format stricter than flash and rejects the standard Codex format. Would be great if this could be fixed, or if pro's /responses could be routed to the native upstream the way flash was.
Activity
PaysNatal commentedon Aug 13, 2026
Same issue here (macOS, Codex + opencode Go https://opencode.ai/zen/go/v1, wire_api = responses, model deepseek-v4-pro). First turn works; any multi-turn request fails with the same 400:
Failed to deserialize the JSON body into the target type: messages[113]: missing field id(earlier also sawInvalid assistant message: content or tool_calls must be set). deepseek-v4-flash works with the identical request body. Subscribing for updates - happy to help test a fix.bobleer commentedon Aug 13, 2026
This looks like two translation bugs rather than a model regression. The fastest check is to capture the gateway's translated
messages[], not just the incoming Responses body: every assistant turn should retaincontent(use an empty string rather than omitting it), preservereasoning_contenteven when it is empty, and replay tool-call IDs unchanged. Themissing field idvariant suggests output items are being reconstructed instead of replayed.We hit the empty-field edge in a DeepSeek-compatible adapter and kept a regression test here: https://github.com/GCWing/BitFun/blob/main/src/crates/adapters/ai-adapters/src/providers/openai/message_converter.rs#L371-L377
If the translated shape is correct, routing Pro to the native Responses upstream (as the reporter suggests) is the clean A/B against the Chat-Completions converter.
hairyf commentedon Aug 13, 2026
Same stack here — Windows, Codex
wire_api = "responses"→https://opencode.ai/zen/go/v1, modeldeepseek-v4-pro. Confirmed: first turn works, every subsequent turn fails with 400 (Invalid assistant message: content or tool_calls must be set/missing field id).deepseek-v4-flashand the official DeepSeek API are fine.Two related symptoms on the same gateway that are worth flagging in this thread:
tools[N].function: missing field 'name'— Codex sends OpenAI-native tools (tool_search,web_search) that have noname; the gateway rejects the whole request ([OpenCode Go] deepseek-v4-pro via Responses API: 400 tools[N].function missing field 'name' (web_search tool rejected) #42090)./responsesSSE stream is non-standard:response.output_text.deltaevents omititem_id/output_index/content_index, there are nooutput_item.added/content_part.addedscaffolding events, andresponse.completedcarries an emptyoutputarray. The official Codex SSE parser drops this text, so instead of a 400 the UI often just shows an empty reply.I'm working around all three with a small local proxy (drops nameless tools + normalizes the SSE stream): https://github.com/hairyf/codex-deepseek-subagent-proxy — it doesn't fix the gateway-side multi-turn conversion bug itself. Let me know if raw request/response captures would help triage.
Sino-Huang commentedon Aug 13, 2026
I call the same api via opencode2 and it gives me this error
Error: response.output_text.delta is missing item_idlmj890810 commentedon Aug 13, 2026
Same issue here — confirming from a second setup:
wire_api = "responses"→https://opencode.ai/zen/go/v1, modeldeepseek-v4-pro(reasoning effort max).messages[6]: missing field "id" at line 1 column 14439(the report above showsmessages[4]). The offending item is the echoed assistant reply from the previous turn (position in the array = history length), so the index is not constant.missing field "id"andInvalid assistant message: content or tool_calls must be set.deepseek-v4-flash→ 200; direct official DeepSeek API → 200.Net effect: multi-turn conversations with
deepseek-v4-prothrough Console Go are currently unusable. Happy to provide more repro data or test a fix.Seegin commentedon Aug 13, 2026
Quick update: in the latest OpenCode Go model catalog,
deepseek-v4-prois served fromhttps://opencode.ai/zen/go/v1/chat/completions(openai-compatible), not/v1/responses; see https://dev.opencode.ai/docs/go/.With
wire_api = "chat"in Codex, the multi-turn 400s described here no longer occur, because the Responses->internal-messages conversion path is bypassed. That is an endpoint migration, not a fix of the underlying conversion bug, which is still tracked by #42090 / PR #40210. Just reporting that the pro-via-OpenCode-Go symptom is no longer reproducible for me.github-actions commentedon Oct 13, 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.