Dead loop: infinite empty assistant messages (tokens=0) after tool call with empty text

[includewudi]

Description

After an LLM returns a tool call with empty/no text content, the agent loop enters an infinite cycle creating empty assistant messages (tokens: {input:0, output:0}) without ever invoking the LLM. The only recovery path is manual compaction.

Reproduction

1. Start an interactive session with a custom provider (in our case, glm-5 via llm-router)
2. LLM returns a tool call (e.g., Read a PNG file) with empty text in the response
3. Tool executes successfully, result is sent back to the LLM
4. On the next loop iteration, the LLM returns an empty/errored response (tokens: {input:0, output:0})
5. Loop continues indefinitely creating empty assistant messages

Session evidence: ses_1bba6f1c4ffe55rFTzStkU2fyM — 162 total messages, two dead zones:

• msg[143-149]: 7 empty assistant messages, all tokens=0
• msg[155-161]: 7 empty assistant messages, all tokens=0
• Recovery at msg[150] and msg[162] via compaction

Root Cause Analysis

The exit condition (prompt.ts L1268-1276)

The while(true) loop at prompt.ts:1248 breaks only when ALL four conditions are true:

if (
  lastAssistant?.finish &&                              // (1) finish is truthy
  !["tool-calls"].includes(lastAssistant.finish) &&     // (2) not tool-calls
  !hasToolCalls &&                                      // (3) no pending tools
  lastUser.id < lastAssistant.id                        // (4) ID ordering
) {
  break
}

When the LLM returns an empty response after a tool result, finish may be "unknown" or unset (condition 1 fails), and the loop continues.

Why safety nets don't catch it

1. DOOM_LOOP_THRESHOLD (processor.ts:424) — Only detects 3 consecutive identical tool calls (same tool name + same input). Does NOT catch empty responses or different tools.

2. isOverflow() (overflow.ts:20-31) — When tokens = {input:0, output:0}, count = 0, so isOverflow() returns false. The compaction safety net never triggers.

3. No max-empty-steps guard — There is no mechanism to detect "N consecutive steps with zero tokens" and force-exit the loop.

Recovery

Only compaction recovers the session — it regenerates context and creates an assistant message with finish: "stop", which passes the exit check.

Suggested Fix

Add a guard in the runLoop to detect consecutive empty responses:

// In the while(true) loop, after processor returns:
if (handle.message.tokens.input === 0 && handle.message.tokens.output === 0) {
  emptyStepCount++
  if (emptyStepCount >= 3) {
    yield* slog.warn("exiting loop: consecutive empty responses")
    break
  }
} else {
  emptyStepCount = 0
}

Alternatively, isOverflow() could treat consecutive zero-token responses as a degenerate case that should trigger compaction or loop exit.

Environment

• opencode: v1.15.5 (installed via Homebrew)
• Provider: custom (glm-5 via llm-router, OpenAI-compatible API)
• OS: macOS (darwin)

Related Issues

• Web: client clock skew can cause repeated assistant responses / prompt loop #28339 — Clock skew causes ID ordering failure in the same exit condition
• Streaming response validation fails when provider returns empty delta.role instead of "assistant" #28427 — Provider returns empty delta.role, stream error prevents finish from being set
• Loop Compacted opencode --version 1.15.5 #28426 — Compaction loop issue

[github-actions]

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

• z.ai/zhipuai finish_reason: "model_context_window_exceeded" is treated as unknown, causing loop instead of stopping #18813: Same root cause — GLM-5/zhipuai provider returns finish: "unknown" with tokens: {input:0, output:0}, causing an infinite loop in the agent. That issue also uses the zhipuai/glm-5 provider and shows identical session JSON with zero-token messages.

If this is a different scenario or a new angle on the same underlying bug, it may be worth cross-referencing or consolidating with #18813.

[GonyRosenman]

I think I hit a related case in interactive TUI, but not an infinite loop.

Environment:

• Windows
• npm global install
• opencode process version: 1.15.12
• provider/model: openrouter/deepseek/deepseek-v4-pro
• mode: build

What happened:
The agent successfully completed an edit tool call on:

src\chamber\engine\sound\setups\preview_director_prompt.py

The edit output was “Edit applied successfully.”

Immediately after that, opencode created a new assistant message that finished normally with stop, but produced no visible text and no tool call. The UI looked like the assistant just silently stopped after editing the file.

From opencode.db:

Previous message:

• message_id: msg_e7d887609001XrMdziBG9kK5Mb
• finish: tool-calls
• tool: edit
• status: completed
• output: Edit applied successfully.

Next assistant message:

• message_id: msg_e7d8896e7001IqIG0mmcgPZNTT
• finish: stop
• tokens: input 427, output 2, reasoning 0, cache read 168320
• parts: step-start, step-finish
• no text part
• no tool part
• no error

The task was not actually finished, the todo table still had pending/in-progress items. So this was not just a cosmetic final empty message, it caused the session to appear to stop mid-task.

This seems related to the empty assistant/tool-call continuation family of bugs, but in my case it was a single silent empty stop after a successful edit, not an infinite empty loop.