Repository navigation
opencode backend: long/complex prompts end with no content ('produced no stream output') #71
Description
Summary
opencode backend is unreliable on long / complex prompts: the response ends with no assistant content and the caller (litellm) sees MidStreamFallbackError: OpenAIException - opencode produced no stream output. Short prompts succeed. claude-code and codex on the identical prompts are reliable.
Repro
Running the TaxCalcBench harness sweep (a ~large 1040 tax-return prompt) through the bridge:
model=opencode/zai-coding-plan/glm-5.1
# short prompt ("say OK") -> HTTP 200 in ~4s, fine
# full tax-return prompt -> "opencode produced no stream output" (fails most attempts)
On a 51-case sweep, opencode/glm-5.1 produced ~1/51 while claude-code/sonnet and codex/gpt-5.5 ran clean to completion.
Diagnosis
src/backends/opencode.tsalready emits keepalive SSE comments during silent stretches (30da47e), so the socket no longer dies.- But on a hard task opencode appears to work silently, emit only keepalives, then exit having produced no gradeable content deltas — which surfaces to the caller as "produced no stream output" (empty stream).
- So the keepalive fix solved socket-death but not the empty-completion case: we never distinguish "still working" from "exited with nothing," and we don't surface why opencode produced nothing (stderr / non-zero exit / internal error event).
Impact
opencode is effectively unusable for long-running agentic benchmarking via the bridge. Had to drop it from the TaxCalcBench harness comparison (kept claude-code + codex). By contrast the streaming harnesses (claude-code, codex) are reliable because they emit content continuously.
Suggested fixes to consider
- When the stream closes with zero content deltas, throw a descriptive
BackendErrorthat includes opencode's stderr tail + exit code (like the kimi path atkimi.ts:332), instead of an empty stream that the caller mislabels as "no stream output." - Investigate whether opencode needs a different invocation for long tasks (e.g.
--print/non-interactive output mode, or reading its final message from the session rather than the live stream). - Consider a completion-based read (poll opencode's session for the final assistant message) rather than relying purely on the live stdout stream, since opencode batches on complex tasks.
Not the sandbox
The sandbox (@tangle-network/sandbox) opencode adapter has a related but separate symptom: empty_visible_output within 60000ms. Same root behavior (opencode silent on long tasks), different adapter/timeout — worth fixing in both.
Activity
drewstone commentedon Jul 17, 2026
Root cause is upstream: anomalyco/opencode#22243
This is a symptom of opencode#22243 — "opencode run produces no stdout output while running" (open, assigned to @kitlangton, PR #33146 linked). opencode's non-interactive
runmode buffers all output until completion — no streaming progress. The upstream reporter proved via the session DB that the agent is making progress (Glob/Read steps ~10s each) while stdout stays empty.That fully explains our symptom: the keepalive keeps the socket alive, but opencode emits no content deltas until the very end (or exits with nothing on a hard task), so litellm sees an empty stream → "produced no stream output." The streaming harnesses (claude-code, codex) don't buffer, which is why they're reliable.
Concrete workaround this reveals for the bridge
The upstream issue shows the result/progress is in opencode's session DB even when stdout is empty. So the durable fix for our backend is a completion-based read: after the run, read the final assistant message from opencode's session (we already capture
internal_session_id) rather than relying purely on the live stdout stream. That sidesteps the upstream buffering entirely.Short term: option 1 above (throw with stderr tail + exit code on zero-content close) still worth doing so failures aren't silently mislabeled.
Tracking upstream: fixed when opencode#22243 / opencode PR #33146 lands (streaming progress in
runmode).drewstone commentedon Jul 17, 2026
Correction: the right fix already exists in agent-dev-container — use
opencode serve, notopencode runIgnore my earlier "read the session DB" suggestion — it's a worse workaround. agent-dev-container's sidecar already solves this properly and cli-bridge should match it.
opencode run --format json— the one-shot mode that buffers all output (upstream opencode run produces no stdout output while running anomalyco/opencode#22243). On long tasks it emits keepalives then finishes with no content deltas.opencode serve(persistent HTTP server) and talks to it via the@tangle-network/sdk-provider-opencodeSDK over its HTTP/event API. Streaming works; therun-mode buffering bug never applies. Seeapps/sidecar/src/interactive/interactive-session-manager.ts:74("headless integration usesopencode serve") andbackends/cli-agent-bindings.tsimportingOpencodeProviderAdapter.Recommended fix
Replace the
opencode runspawn insrc/backends/opencode.tswithopencode serve+ the@tangle-network/sdk-provider-opencodeclient (or a thin HTTP client to the served session), mirroring the sidecar. This makes opencode as reliable as claude-code/codex on long agentic prompts and removes the dependence on upstream #22243 landing.drewstone commentedon Oct 30, 2026
The empty-stream case is now diagnosed and the long-task case streams: a zero-content close names opencode's stderr tail and exit (src/backends/opencode.ts:389), #225 reads the error opencode actually writes and #264 carries its HTTP status, and #228/#266 forward reasoning, tool-call starts and tool outcomes as they happen, so a long agentic turn through
opencode run --format jsonis no longer silent until exit. Bridge-driven opencode cells have been completing >10-minute build phases since August (#105). Theopencode servemigration was not needed; the sandbox adapter symptom stays with @tangle-network/sandbox.