Aborted provider stream recorded as clean stop (finish=unknown, zero usage, no text) — subagent returns empty with no error

[fernanDOTdo]

Description

When a provider stream terminates mid-generation without a finish reason or usage chunk, opencode records the assistant message with finish=unknown, zero tokens, and no text part, then exits the agent loop as if the turn completed normally. No error is logged or surfaced.

For a subagent this means the parent receives an empty task result with no error signal — it cannot distinguish "provider dropped the stream" from "agent finished with nothing to say."

Observed on 1.18.3 with a subagent on fireworks-ai/accounts/fireworks/models/deepseek-v4-flash: 6 healthy tool-call turns, then a ~34.5s stream that emitted ~15.8 KB of reasoning and simply ended — no text, zero recorded usage, finish=unknown, nothing in the logs. The loop exited cleanly and the parent's task tool returned an empty <task_result>.

Expected: a stream that ends without a finish reason (or with zero content and zero usage) is treated as an error and retried — or at minimum surfaced as a distinct truncated finish state so callers can react (e.g. a subagent's parent retrying or failing the task explicitly).

Plugins

superpowers@git+https://github.com/obra/superpowers.git

OpenCode version

1.18.3

Steps to reproduce

Intermittent by nature (depends on the provider dropping the stream mid-generation):

1. Run an agent on a model/provider combination that streams long reasoning segments (observed: Fireworks deepseek-v4-flash).
2. Have the provider connection terminate mid-turn, after reasoning deltas but before any text/tool call and before the usage chunk.
3. Observe the assistant message persisted with finish=unknown and zero tokens; the loop exits; no error anywhere.

Operating System

macOS 26.5.2

Terminal

supacode

[github-actions]

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

• [BUG] Subagent terminates prematurely mid-execution but reports completed #32132: Subagent terminates prematurely mid-execution but reports completed — describes the same symptom of a subagent stopping early and the task tool reporting success with no error signal to the parent agent.

If your issue is specifically about the provider dropping the stream (rather than a timeout/task tool behavior), it may be a distinct root cause worth tracking separately. Please review #32132 and comment there or close this one if it matches your situation.

[fernanDOTdo]

Reviewed #32132 — related symptom family, but a distinct root cause; this one is worth tracking separately.

#32132 (per the confirmed forensics in its comments): a streaming tool execution (bash) is aborted mid-flight; the child DB row records Tool execution aborted, and the parent sees completed with empty/partial output. The failure happens while a tool runs, and an abort is recorded somewhere.

This issue: no tool is in flight. The provider stream itself ends mid-generation — after reasoning deltas, before any text/tool call, and before the finish/usage chunk. opencode then persists the assistant message with finish=unknown, zero usage, zero content, and no error recorded anywhere, and the loop exits as if the turn completed. The parent's task result is completely empty, not partial.

Different failure point (stream finalization vs. tool-execution abort propagation) and a different signature (finish=unknown + zero usage + zero tokens vs. Tool execution aborted in the child). The requested fix here is narrower: a stream that ends without a finish reason (or with zero content and zero usage) should be treated as an error/retry, or surfaced as a distinct truncated finish state.

[Davide95]

I observed several turns using openai/gpt-5.6-sol where OpenCode recorded:

{
  finish: unknown,
  tokens: {
    input: 0,
    output: 0,
    reasoning: 0
  },
  cost: 0
}

The assistant message contained no text or completed tool call. The runtime log showed the stream starting and the loop then exiting normally, with no provider error or retry. Sending another message started a fresh turn.

The 1.18.8 loop still treats this terminal finish="unknown" state as a completed turn.

[Maizify]

#39456

I'm seeing a closely related failure mode on 1.18.4+ with a custom Anthropic provider (deepseek-v4-pro):

The stream drops during or before a tool_use in a subagent. Unlike #37852 where the loop exits cleanly with finish=unknown, in my case opencode enters the tool execution state and the subagent hangs with MessageAbortedError ("Tool execution aborted") for 5–53 minutes. The message row still shows {input: 0, output: 0} — i.e. opencode never received any response tokens from the stream.

Key observations from opencode.db:

100% reproducible from 1.18.4 onward (1.18.3 occasionally succeeded), also present on 1.18.8 and 1.18.9.
Main-agent tool calls in the same session are unaffected; only subagent tool execution is affected.
Intermittent within the same parent session: retrying the same subagent task often succeeds immediately. This rules out a session-global state corruption.
Highly concentrated in long-lived parent sessions with heavy tool usage, but session size alone is not sufficient — another parent with 5000+ messages had zero failures.
macOS 15.7.7, Node v24.13.1, Anthropic protocol via custom provider.

The finish=unknown / zero-token pattern described here and the Tool execution aborted pattern I'm hitting both point to the same root cause: the provider stream terminates silently and opencode's stream handler does not recover or retry. The difference is just when the drop occurs — before a tool_use (→ empty turn) vs. during one (→ hung tool execution).

[abigaha]

Confirmed independently on OpenCode 1.18.9, Linux, using a custom OpenAI-compatible provider (@ai-sdk/openai) and a general subagent inheriting the primary model.

The child session completed several normal turns first. Its last healthy assistant turn had finish="tool-calls" with non-zero usage and completed read/glob calls. The next persisted assistant message was:

{
  "finish": "unknown",
  "tokens": {
    "input": 0,
    "output": 0,
    "reasoning": 0,
    "cache": { "read": 0, "write": 0 }
  }
}

That terminal message had no text part and no completed tool call. The agent loop then logged exiting loop; the parent task received no structured failure indicating that the delegated work was incomplete.

Relevant controls checked:

• general.steps = null
• general.maxSteps = null
• no request timeout configured
• the child was only a few agentic iterations into the task
• OpenCode was already at the latest release (1.18.9)

A useful SQLite diagnostic for affected sessions is:

SELECT
  json_extract(data, '$.finish') AS finish,
  json_extract(data, '$.tokens.input') AS input_tokens,
  json_extract(data, '$.tokens.output') AS output_tokens,
  json_extract(data, '$.time.completed') AS completed_at
FROM message
WHERE session_id = '<child-session-id>'
ORDER BY time_created DESC
LIMIT 1;

This returned unknown | 0 | 0 | <timestamp> for the interrupted child. Other child sessions under the same parent completed normally, so this is not a configured step ceiling or a parent-session-wide stop condition.

The actionable issue is the lifecycle contract: finish="unknown" plus zero usage/content must not be converted into a successful/empty task result. It should either resume/retry the child or propagate an explicit interrupted/error result to the parent so orchestration can recover.