Mid-word streaming truncation with Muse Spark via Zen (shell -> shel, thinking cut with space and dot)

[claell]

Mid-word response truncation with Muse Spark via Zen (shell → shel, thinking truncated)

Environment

• App: OpenCode Desktop 1.2.0-beta.12
• OS: Windows 11 (PowerShell 5.1, platform win32)
• Provider/model: OpenCode Zen muse-spark-1.2-contributor-free (also reproduced with other Zen free models)
• Date: 2026-08-30

Description

Assistant responses are truncated mid-word in the TUI even for short turns. Two recent examples from the same session:

• An assistant message listing CLI tool flags ended with patch plus shel instead of patch plus shell — the word shell lost its final l mid-stream.
• An internal reasoning/thinking stream ended with a truncated fragment containing a space and dot (visible in the thinking trace) — also mid-word.

The truncation is not announced to the user or to the assistant; the assistant continues as if the full text was delivered. It affects both visible assistant text and the streaming thinking trace, and reproduces intermittently but multiple times within a single session.

Steps to reproduce

1. Open OpenCode Desktop on Windows with Zen configured and muse-spark-1.2-contributor-free selected.
2. Ask the assistant to perform a short multi-tool task that emits tool-related text (e.g., describing patch plus shell/apply_patch usage, or streaming reasoning).
3. Observe the streamed assistant output and thinking trace — intermittently a word is cut after shel or a thinking fragment ends with ..

Expected behavior

Short responses should stream to completion without mid-word truncation. If a provider stream is truncated, OpenCode should surface a clear truncation/continuation signal instead of silently cutting text.

Actual behavior

• Text is cut mid-word (shell → shel) and thinking is cut with a trailing ., both without error or retry signal.
• No indication is shown that the response was truncated.
• The assistant is unaware truncation occurred.

Relation to existing issues

Checked existing truncation issues before filing (search queries truncation, truncated):

• BUG REPORT: Output Truncation During Long Responses #39393 Output Truncation During Long Responses — covers silent truncation of long narrative outputs (>2500 chars). This report is related but distinct: truncation here occurs for short tool-related messages, mid-word, and also affects the thinking stream.
• [Opencode Go] Frequent jitter / possible truncation when calling opencode-go/muse-spark-1.2 via Codex (opencodex proxy, openai-chat) #43680 [Opencode Go] Frequent jitter / possible truncation when calling opencode-go/muse-spark-1.2 via Codex — covers stream truncation mid tool-call (openai-chat adapter !sawFinish && pendingToolCalls). Related model, but different harness (Codex via opencodex) — this is native OpenCode Desktop.
• core: recover gracefully from truncated provider streams #38747 core: recover gracefully from truncated provider streams and Assistant reply chunks appear as separate user messages (empty prompts, mid-sentence truncation) with interleaved-reasoning model via Zen #44141 Assistant reply chunks appear as separate user messages … with interleaved-reasoning model via Zen — both track truncation recovery for provider streams and interleaved reasoning. This report adds a concrete Windows/Desktop reproduction with muse-spark via Zen where both assistant text and thinking are truncated mid-word without recovery.

Not a duplicate of #18108, #39393 long-output, or #45186 glob limits — those address tool-call or output-length limits, not interactive streaming mid-word cuts.

Additional context

• Truncation is intermittent but reproducible within one session (seen at least twice for thinking and once for assistant text).
• No custom provider or gateway involved in this path — direct Zen via OpenCode Desktop.
• Happy to provide redacted logs or a minimal reproduction prompt on request. No personal data, API keys, or local paths included.