[FEATURE]: Support Responses API for deepseek-v4-flash on opencode-go

[YiRan0]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

DeepSeek's formal deepseek-v4-flash-0731 checkpoint (released Jul 31, 2026) natively supports the OpenAI Responses API (https://api.deepseek.com → /v1/responses). However, opencode-go only serves deepseek-v4-flash via /v1/chat/completions:

• POST https://opencode.ai/zen/go/v1/responses with deepseek-v4-flash → HTTP 400: Error from provider (Console Go): Upstream request failed
• The same endpoint works fine for GPT-5.x models (e.g. gpt-5.6-luna)
• The same request succeeds against DeepSeek's official Responses API

This blocks Codex-style clients (which speak the Responses protocol) from using DeepSeek V4 Flash through opencode-go.

Proposed behavior:

1. Switch deepseek-v4-flash upstream to the 0731 checkpoint that supports Responses API natively.
2. Forward /v1/responses requests for deepseek-v4-flash to the upstream Responses endpoint (like GPT-5.x models).
3. Keep /v1/chat/completions working for backwards compatibility.

Additional context:

• DeepSeek official docs: https://api-docs.deepseek.com/zh-cn/guides/responses_api
• Related: DeepSeek V4 Flash formal version (0731) — is it already live on OpenCode Go/Zen? #39823 (is the 0731 checkpoint live?), [Zen] AuthError: "Request blocked by upstream provider" — all Zen models broken, account recreated #39827 (Go gateway outage today)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: add Responses API support for Go service #23655: [FEATURE]: add Responses API support for Go service — requests the same /v1/responses endpoint for the Go service, covering all Go service models. Your request is more specifically scoped to deepseek-v4-flash and the 0731 checkpoint, but the underlying ask overlaps significantly.

[LuckyPro-X]

👍

[lesacar]

for your 3rd point, there should also be a way to tell which API you're using (clear distinction saying you're using Completions or you're using responses) , since I've only been using deepseek, I don't know how to tell if "retained reasoning" is turned on in opencode which requires the new responses api

[cubelitblade]

Makes sense for the free version on Zen too — and since OpenCode GPT is Responses-only, maybe just keep DeepSeek the same for consistency?

[JINGMINGRUO]

Adding my support here. DeepSeek's official API already natively supports the Responses API for deepseek-v4-flash (POST https://api.deepseek.com/v1/responses works with this model), so supporting it on opencode-go should be straightforward: forward /v1/responses requests for DeepSeek V4 Flash to the official upstream Responses endpoint, the same way GPT-5.x models are already handled. Since opencode-go already serves /v1/responses for the GPT models, adding DeepSeek V4 Flash would keep the behavior consistent and let Codex-style clients use DeepSeek through opencode-go. I hope the team can prioritize this — it is just a small mapping on top of an officially supported upstream.

[dreamfarer-space]

So, does that mean Codex still cannot use DeepSeek V4 Flash through OpenCode Go?

[JINGMINGRUO]

Short answer: not yet, but a fix is ready and just needs to be merged.

The problem: OpenCode Go currently serves DeepSeek V4 Flash through a chat-completions upstream and converts that stream into a Responses-API stream. The conversion was missing the lifecycle events Codex relies on (response.created, response.output_item.added, response.content_part.added, response.output_item.done), so Codex turns hang or fail.

PR #40210 fixes that conversion, so Codex should be able to use DeepSeek V4 Flash through OpenCode Go once it is merged and deployed.

In the long run, the more solid fix is native support: forward /v1/responses for deepseek-v4-flash directly to DeepSeek's official Responses endpoint, like OpenCode Go already does for GPT models, instead of translating from chat completions. That is what #39829 / #23655 ask for.

If this affects you too, a thumbs-up or a short comment on #40210 would help it get reviewed and merged.

[ChangedenCZD]

for your 3rd point, there should also be a way to tell which API you're using (clear distinction saying you're using Completions or you're using responses) , since I've only been using deepseek, I don't know how to tell if "retained reasoning" is turned on in opencode which requires the new responses api

在 opencode-go 网关自动适配，参考其他中转站。
In opencode-go gateway, automatic adaptation is carried out, referring to other transfer stations.

[KeLearns]

Suggestion: pass through DeepSeek's official /v1/responses instead of converting from chat/completions

First of all, thanks for the work on #40210 — much appreciated. I'd like to suggest a simpler and more robust direction for DeepSeek V4 Flash on the Go service: just proxy the request through to DeepSeek's official /v1/responses endpoint, the same way GPT-5.x models are already handled natively.

DeepSeek's official API has natively supported the Responses API for deepseek-v4-flash since the 0731 checkpoint. I verified this directly:

• POST https://api.deepseek.com/v1/responses with model: deepseek-v4-flash works — including tools ({"type":"web_search"} is accepted and returns proper web_search_call output items).

The chat-completions → Responses conversion layer on the Go service, on the other hand, is currently breaking requests in at least three independent ways for this model:

1. Missing lifecycle events (response.created, response.output_item.added, response.content_part.added, response.output_item.done) — already tracked in fix(console): emit complete Responses-API SSE lifecycle for converted streams #40210. Codex-style clients hang or fail without them.
2. web_search tool declaration → HTTP 400: if the request's tools array contains {"type":"web_search"} at any position, the upstream returns Failed to deserialize the JSON body into the target type: tools[N].function: missing field 'name' (N varies with tool ordering). The deserializer seems to treat unknown tool types as malformed function tools. Verified with both Codex CLI and a plain curl against opencode.ai/zen/go/v1/responses; the identical request succeeds against DeepSeek's official endpoint.
3. reasoning_content dropped across tool-call turns in thinking mode (the DeepSeek silently stops executing (interleaved reasoning_content dropped in tool call messages) #35689 / thinking is enabled but reasoning_content is missing in assistant tool call message at index ... #25758 / DeepSeek thinking mode: reasoning_content not passed back for tool call turns, causing 400 errors #24722 / DeepSeek V4 Pro SiliconFlow Bad Request: The reasoning_content in the thinking mode must be passed back to the API. #28974 family) — which makes DeepSeek reject subsequent turns or silently stop mid-task.

All three issues disappear if requests for deepseek-v4-flash are forwarded verbatim to the official Responses upstream instead of being parsed/rebuilt/converted by the gateway. Since the official endpoint already supports everything the Responses protocol needs (including native web search), a passthrough would also fix the Codex/cc-switch use case end-to-end.

Would it be possible to route DeepSeek models on /v1/responses directly to api.deepseek.com/v1/responses?

[metrofun]

While native DeepSeek Responses support is being worked on in #40210, there is an alternate path that does not depend on OpenCode Go’s Chat-to-Responses stream conversion.

I maintain Swobu, a local compatibility gateway. Codex keeps using wire_api = "responses" against Swobu, while Swobu translates the request to DeepSeek’s native streaming Messages endpoint.

Install the current release:

curl -fsSL https://swobu.com/install.sh | sh
swobu

Add a DeepSeek target in Cockpit using DEEPSEEK_API_KEY, then configure ~/.codex/config.toml:

model = "deepseek"
model_provider = "swobu"

[model_providers.swobu]
name = "Swobu"
wire_api = "responses"
base_url = "http://127.0.0.1:7926/c/dev/v1"

This path avoids OpenCode Go’s synthesized Responses stream entirely. Swobu owns the Responses lifecycle returned to Codex and uses DeepSeek’s native provider surface for the upstream tool loop.

[exposir]

⬆️

[JINGMINGRUO]

Small follow-up now that go/v1 natively forwards DeepSeek V4 Flash to its official /v1/responses: the runtime already accepts DeepSeek's full reasoning-effort set (none/low/high/max). I verified low and max through opencode.ai/zen/go/v1/responses, and both return 200.

The remaining gap is metadata: GET /zen/go/v1/models only returns basic fields for deepseek-v4-flash (id/object/created/owned_by), and the models.dev entry has empty reasoning_options. As a result, Codex-style clients and tools like CC Switch only show none/high for this model.

Would it be possible to advertise the supported reasoning efforts for deepseek-v4-flash (e.g., in /v1/models or the Go docs/model catalog)? DeepSeek's official docs list the effort set here: https://api-docs.deepseek.com/zh-cn/guides/thinking_mode