opencode-go / deepseek-v4.1-flash: the finished answer is returned in reasoning_content while content is empty — ~7% of turns, 0% on the official API in the same session

Summary

Through opencode-go with deepseek-v4.1-flash, a substantial fraction of turns come back with:

• content empty (no text block)
• no tool_calls
• the complete, finished, user-facing answer sitting in reasoning_content

The turn is reported as a normal completion. The user sees an empty reply.

This is not "the model thought and stayed silent". The reasoning field contains the finished deliverable — headings, bullet lists, wording addressed to the reader. The model expected to emit it as content and never did.

Worse: the model then reads the user's complaint about the empty reply and fails the same way again.

Environment

• Client: DeepSeek Harness (agent harness), OpenAI-compatible route via @earendil-works/pi-ai 0.87.1. The required x-opencode-session header is sent.
• Provider: opencode-go
• Endpoint: https://opencode.ai/zen/go/v1/chat/completions
• Model: deepseek-v4.1-flash
• Settings: reasoning_effort=high, max_tokens=384000
• Date: 2026-10-10

Controlled comparison — one session, three gateways

Same session, same harness, same machine, same tools, same system prompt. The provider was switched mid-session, so the only variable is the gateway.

¹ reasoning-only = has a reasoning block, no text block, no tool_calls, followed by a user message or session end (so the turn was supposed to produce an answer).

The first two rows are the same model id on two different gateways: 9 vs 1.

All 9 opencode-go cases occurred between 2026-10-10 13:22 and 14:23 local time — i.e. everything after the switch to opencode-go at 13:16. Zero before it, across the same session.

What the reasoning-only turns contain

Short excerpts from the reasoning field of turns that produced no content at all:

• turn 86 — "The user says I didn't output anything — I put the final reply in the thinking chain. I need to just write the actual final response now."
• turn 87 — "The user says I didn't output anything — my final response went into the reasoning instead."
• turn 90 — "The user is saying I did an empty output AGAIN."
• turn 107 — "The user says I produced an empty reply AGAIN. I need to output the report now, visibly."

Turns 86, 87, 90 and 107 are each a single-step turn: the user complained that the reply was empty, the model produced the full reply into reasoning_content again, and content was empty again. This repeated four times.

Suspected trigger — not confirmed

The upstream vLLM DeepSeek V4 tool-call parser routes the entire completion to reasoning_content when the model does not emit the thinking terminator, at a reported ~20–25% misroute rate — see vllm-project/vllm#48645; vLLM added an opt-in fix to expose the unterminated block as content in #50753.

I am not claiming that is the cause here. I have not captured the raw SSE stream to check whether the terminator is present on the failing turns. Related opposite-direction report: ai-dynamo/dynamo#8901.

Repro

1. Point any agent harness at https://opencode.ai/zen/go/v1/chat/completions, model: deepseek-v4.1-flash, reasoning_effort: high.
2. Run a tool-heavy loop for a while.
3. Watch for turns where content is empty, tool_calls is absent, and the finished answer is in reasoning_content.

Reported at ~2–3 per session by other users as well, in a harness-side report of the same symptom: deepseek-ai/deepseek-harness#8553.

Asks

1. Is deepseek-v4.1-flash on opencode-go served by a path that parses the DeepSeek V4 thinking terminator? If the terminator is sometimes missing, that is the whole bug.
2. If so, can the gateway expose an unterminated reasoning block as content (as vLLM does in Feature Request: Voice Mode, First-Class Browser Automation, Goal-Driven Task Loop, and In-App Plugin Discovery #50753) instead of routing the entire answer into reasoning_content?
3. If this is a known limitation, please document it. Clients currently cannot distinguish this from a genuine empty completion without reading reasoning_content as a fallback, which is not something a client should have to do to get its own answer.