A reasoning-only turn is reported as completed: no answer, no tool call, and the raw reasoning is left on screen

[ssjob123]

A turn that produced only a reasoning block is treated as completed — no visible answer, no tool call, and the UI then leaves the raw reasoning on screen

Related: this is the uncovered half of the 2026-07-24-empty-model-response-is-retryable fix. It is not the same as "rendering shows reasoning by mistake" (that part is correct) — the defect is that a reasoning-only turn is never recognised as an empty response, so nothing retries it.

Environment

• DSH @deepseek-ai/dsh 0.1.5-rc.1 (Web profile, dsh web)
• Model: deepseek-official / deepseek-flash, reasoningEffort: max
• Windows 11 (Chinese), Windows PowerShell 5.1, Node v26.4.0
• Session that reproduced it: session-71f620f9-… — 1.54 MB compressed, 420 zstd frames, 4.19 MB decompressed JSONL

Symptom

Repeatedly, a turn ends with no assistant text and no tool call. The conversation appears to "hang": the only thing on screen is the model's reasoning, and the collapsed think-row summary is frozen on whatever the last reasoning line happened to be (in my captures, always the literal string **发。**, which is the model's own shorthand for "about to call a tool").

Sending any further message resumes normally, which is the giveaway: the turn was not aborted, it completed.

Hard evidence from the session log

seq 788  assistant/message  turn 20, step 2
         content = [ { type: "reasoning", text: <2705 chars> } ]      <-- single block, no text, no tool-call
         ... ends with: **好。** ... **发。** ... **嗯，不确定会不会又被用户说卡。我要快。** ... **发。**
seq 789  step/end
seq 790  turn/end  {"kind": "completed"}                              <-- no tool/call event in between

The same session contains 8 such messages with the identical shape — reasoning only, no text, no tool-call — at seq 511 / 529 / 597 / 741 / 775 / 788 / 806 / 814, every one of them ending in that same "about to send" phrase.

Root cause

Two independent checks both miss this case.

1. Empty-response detection only counts zero blocks, not zero visible blocks

@deepseek-ai/dsh-llm-deepseek lib/index.js L1239:

reason.kind === "stop" && order.length === 0

A reasoning block calls open("reasoning") and therefore participates in order. So a stop that carried only reasoning is not empty by this test and is never retried.

The intent is already documented in @deepseek-ai/dsh-llm lib/types/error.js, where EMPTY_RESPONSE_CODE is annotated:

an empty message silently ends the turn with nothing for the user or the loop to act on

The implementation's boundary (order.length === 0) is narrower than that stated intent.

2. The agent loop only looks for tool calls

@deepseek-ai/dsh-agent-loop lib/index.js L1115-1119:

if (finish.kind === "max-tokens") return { kind: "max-tokens" };
const toolCalls = message.content.filter((b) => b.type === "tool-call");
if (toolCalls.length === 0) return { kind: "completed" };   // <-- reached here

Nothing inspects whether the message contained any visible text. With no tool call it returns completed, the turn closes and control goes back to the user.

Note the ordering also rules out an output-budget explanation: the recorded termination is completed, not max-tokens, so maxTokens was not exhausted.

3. Why the UI leaves the reasoning visible

@deepseek-ai/dsh-client-ui-chat lib/client.js:

• reasoningHidden (≈ offset 152378) requires turnProcess.spec.answerStep === data.step && spec.inlineReasoning && !open. Only an answer step hides its reasoning. A step with no visible text is not an answer step, so reasoningHidden === false and the ReasoningRow renders as-is.
• ReasoningRow (≈ offset 143626) uses latestLine(text) for the collapsed summary while running — so it always shows the last line, which is exactly why every stalled turn I captured ended on the identical phrase.

So the visible symptom is a compound of (2) and (3): the loop accepts a contentless turn, and the UI then has no answer text with which to demote the reasoning into the collapsed process area.

Suggested fixes

#	Package / file	Location	Change
1	@deepseek-ai/dsh-llm-deepseek lib/index.js	L1239	Widen order.length === 0 to "no visible block (text / tool-call)", so a reasoning-only stop is classified as EMPTY_RESPONSE and becomes retryable — matching the intent already stated in the EMPTY_RESPONSE_CODE comment
2	@deepseek-ai/dsh-agent-loop lib/index.js	L1115-1119	Before toolCalls.length === 0 → completed, add a branch for "no visible text and only reasoning": retry the step, or at minimum emit a user-visible notice, instead of ending the turn silently
3	@deepseek-ai/dsh-client-ui-chat lib/client.js	reasoningHidden (≈152378), ReasoningRow summary (≈143626)	The answerStep === data.step requirement means a contentless step is the one case that most needs its reasoning collapsed; consider hiding reasoning whenever the step produced no visible text. The latestLine summary should also carry a truncation indicator so a half-sentence of thinking cannot be mistaken for an answer
4	@deepseek-ai/dsh-llm lib/types/error.js	EMPTY_RESPONSE_CODE	Align the comment and the implementation (comment describes the failure mode correctly; the check only covers zero blocks)

Notes / limitations, stated honestly

• assistant/attempt is not written for successful attempts, so the concrete finish_reason is not in the log. "Not max-tokens" is inferred from turn/end = completed.
• Session size is not established as a cause. Compaction defaults are thresholdRatio: 0.8 with DEFAULT_CONTEXT_WINDOW = 1e6, i.e. ≈ 800k tokens; the affected sessions are ~4 MB decompressed, roughly 300–400k tokens by the token meter's 4-chars-per-token heuristic, and the event log contains no compaction event at all. Large context plausibly makes the failure more likely and certainly makes each step feel slower, but I cannot claim causality. Worth noting dsh-compaction-basic's own README flags that 4-chars-per-token under-prices CJK text, so real Chinese sessions cross the threshold later than the heuristic suggests.
• reasoningEffort: max is a high-suspicion but unproven contributor: it lengthens reasoning and therefore raises the chance that the stream tails off right where a tool call was due. No controlled A/B was run. Lowering it to high is the practical mitigation until the loop is fixed.

Reproduction recipe (for whoever picks this up)

Session files are multi-frame zstd — zlib.zstdDecompressSync returns only the first frame (~0.2 KB). Split on the frame magic 28 B5 2F FD and decompress each frame separately; then look for assistant/message records whose content array has no text and no tool-call block, and read the following turn/end — it will say completed.

[PerryLink]

核实结论：属实，三层断言都与源码逐字吻合，而且这正是你引述的那个修复未覆盖的另一半。

1. 空响应判定只数块数：packages/llm/llm-deepseek/src/translate.ts:135 —— reason.kind === 'stop' && order.length === 0；reasoning 块经 open('reasoning') 进入 order（:160），所以纯 reasoning 的 stop 不会被判 EMPTY_RESPONSE、不重试。
2. agent-loop 收尾只过滤 tool-call：packages/core/agent-loop/src/agent.ts:484-487 —— 无 tool call 即 completed，没有任何地方检查可见文本。
3. UI 侧：answerStep 只授予含回复内容的步（ui-chat/src/client/turn-process.ts:117-122、AssistantNodeView.tsx:23-27），纯 reasoning 步 answerStep=null、不折叠；ReasoningRow 摘要 running 时显示最后一行（ReasoningRow.tsx:13,30）。
4. 你引述的 2026-07-24 修复属实：commit 207aab9「classify empty model completions as retryable EMPTY_RESPONSE」（PR 有人封装成独立桌面应用吗 #607），正是 translate.ts:135 的判定 —— 纯 reasoning 是其未覆盖的一半；error.ts:30-39 的注释「nothing for the user or the loop to act on」的实现边界确实窄于意图。

修法方向：translate.ts 把空判定放宽为「无可见块（text / tool-call）」，或 agent.ts:487 前补「仅 reasoning」分支重试；UI 折叠随修复自然缓解。（编译产物行号未逐一核对，表达式一致。）