DeepSeek Harness turn completed after reasoning-only step

If the model's last response contains only reasoning, finish.reason is stop, the interface shows neither an answer nor a tool call, and yet the turn reports completed, the model did not decide it was done; the decision chain treated "no answer" as "task complete". According to Discussion #9990, such turns go idle silently, and the user must send another message to move them forward. The sections below cover the decision chain, three handling paths, and a deterministic reproduction.

What DeepSeek Harness shows when the final step is reasoning-only

Three features appearing together identify this case rather than an ordinary model pause. Check the symptom first, then the session record:

1. The turn ends as completed. Expected: not an error and not aborted.
2. The last assistant message contains only a reasoning block. Expected: no text and no tool-call.
3. The final answer is empty while the task is unfinished. Expected: a file was not created or a command never ran.
4. The user sends "continue". Expected: the model usually finishes the work, which shows that capability and context are present and only the finalization decision is missing.

DeepSeek Harness call chain: two checks turn "no answer" into "task complete"

According to the community's source review in the thread, the problem is not one adapter but the combination of "the adapter's empty check is too narrow" and "the loop never looks at content". For the overall loop structure, see the DeepSeek Harness turn walkthrough; two steps explain the failure:

1. llm-pi-ai's mapStopReason returns EMPTY_RESPONSE only when message.content.length === 0. Expected: a response holding only a reasoning block has a non-zero length, so it passes as a normal stop.
2. At step finalization in agent.ts, agent-loop filters for tool-call and returns { kind: 'completed' } when the count is zero. Expected: it never checks for visible text.
3. As a result, "no output, no action" and "the model really finished" are indistinguishable in state. Expected: the retry mechanism is never triggered.

DSH plugin fixes: change the check, steer, or retry

All three paths stop an empty answer from counting as completion; they differ in whether you change the provider route, a plugin event, or the frontend. Fix the current provider with path 1, avoid core changes with path 2, and use path 3 as a temporary backstop.

Path 1: fold reasoning-only stops into EMPTY_RESPONSE

This is the smallest change and its scope is limited to the pi-ai route: treat "no text and no tool call" as an empty response and reuse the existing retry policy.

1. In packages/llm/llm-pi-ai/src/stream.ts, find case "stop" inside mapStopReason. Expected: the stop branch is located.
2. Change the empty check from content.length === 0 to "no text block and no tool-call block". Expected: reasoning blocks no longer count as visible content.
3. Keep the existing EMPTY_RESPONSE_CODE and failure structure. Expected: the upper retry policy takes over unchanged.
4. Rerun the same reasoning-only response. Expected: it is marked as a retryable error instead of a normal stop.

case "stop": {
  const visible = message.content.some(
    (b) => (b.type === "text" && b.text.trim() !== "") || b.type === "tool-call",
  )
  if (!visible) {
    return { kind: "error", failure: { code: EMPTY_RESPONSE_CODE } }
  }
  return { kind: "stop" }
}

Path 2: use a turn-stopping plugin to steer the agent

If you do not want to change core, hook agent/turn-stopping and inject a "continue" reminder before the turn actually finalizes. According to the discussion, that event is dispatched on the finalization path in agent.ts, so a plugin can see the last message and call agent.steer.

1. Create a local plugin and register an agent/turn-stopping listener. Expected: the listener is called during turn finalization.
2. Read the last assistant message and check for no tool-call and no non-empty text. Expected: the plugin can classify the final message.
3. On a match, call agent.steer with the stall-guard source and the notice form. Expected: a reminder is injected with the intended source and form.
4. Cap continues at two per turn with a counter. Expected: the loop stops after two steers instead of spinning.
5. Rerun with the same failing proxy. Expected: the run continues from step one to step five, creates the file, and produces a normal final answer.

// Logic sketch; confirm event payload fields against the local dsh-agent-loop types.
if (!hasToolCall && !hasVisibleText && steered < 2) {
  steered += 1
  await agent.steer("The previous step produced no output and no action. Continue the task.", {
    source: { kind: "stall-guard" },
    form: "notice",
  })
}

Path 3: make the frontend surface the empty answer

If the runtime cannot change yet, at least turn the silent failure into something visible and clickable. This is a visibility patch, not a root fix:

1. When a turn ends, check both the end reason and the final text. Expected: both values are available when rendering.
2. When the reason is completed and the final text is empty, do not render it as a normal completion. Expected: the empty turn is not shown as success.
3. Show a clear message and a retry entry. Expected: the user sees an actionable prompt.
4. When the user clicks, start the next turn as a new message. Expected: the model generates again instead of staying on an empty answer, while the stored state remains completed.

How to reproduce the DeepSeek Harness empty turn with a proxy

Verifying the three paths requires a stable reproduction, not waiting for the model to make a rare mistake. The discussion gives a deterministic method:

1. Put a small proxy in front of an OpenAI-Responses endpoint and have it handle only the first /v1/responses request. Expected: only the first request is modified.
2. Remove message and function_call items plus output_text and content_part events from the SSE stream, keeping only reasoning. Expected: the stream carries reasoning only.
3. Point a provider configured with api: openai-responses at the proxy and use a model with reasoning. Expected: requests reach the proxy.
4. Send a task such as "create a.txt and report completion". Expected: one step, turn_end is completed, the final text is empty, and the file was not created.
5. Apply any one of the fixes and rerun. Expected: the step count and the file result change.

Boundaries and verification for the DeepSeek Harness empty turn

Not every empty answer deserves a continue; the check must require "final step, no text, no action" together. Otherwise normal finalization turns into a loop:

1. A final step with short text is a normal answer. Expected: no continue is triggered.
2. A final step with a tool call is still executing. Expected: the tool result drives the next turn.
3. A turn ended by an explicit user interruption. Expected: a plugin steer does not pull it back.
4. A turn that already continued twice with no output. Expected: stop and expose the problem instead of adding attempts.
5. Leaked tool-call markers inside the reasoning. Expected: treat it as a different adapter problem, not something steering can mask.

Source: Discussion #9990.