opencode-go/muse-spark-1.2: frequent 'upstream stream ended mid tool call without a terminal signal — possible truncation' in streaming tool calls (Codex App via ocx, Pi direct OK)

[fede-oss]

Client or integration

Codex App (also reproduced via Pi coding-agent 0.83.0 when routed through OpenCodex proxy)

Area

Provider adapter

Summary

muse-spark-1.2 via opencode-go (adapter: openai-chat, baseUrl: https://opencode.ai/zen/go/v1) fails frequently in streaming tool-call turns with:

upstream stream ended mid tool call without a terminal signal — possible truncation

Source is src/adapters/openai-chat.ts:1718-1726:

const sawFinish = finishReason !== undefined;
if (!sawFinish && pendingToolCalls.length > 0) {
  yield { type: "error", message: "upstream stream ended mid tool call without a terminal signal — possible truncation" };
}

The upstream SSE emits response.created / tool deltas but closes without finish_reason, [DONE], or response.completed. The model is reasoning-heavy and the turn is truncated mid-JSON, leaving pending tool calls un-finalized. Same model via Pi direct to opencode-go (no ocx) is fine — this isolates the failure to the ocx streaming proxy layer, matching anomalyco/opencode#40888 matrix (stream:true + tools fails, stream:false + tools works).

Expected: streaming tool request should produce a complete terminal sequence or a structured retryable error, or automatically fallback to buffered mode like the opencode#40888 workaround (stream:false + reframe as SSE).

Reproduction

1. ocx start --port 10100 (default, opencodex 2.26.0)
2. Pi/Codex config:

   {
     "defaultProvider": "opencode-go",
     "defaultModel": "muse-spark-1.2-contributor",
     "defaultThinkingLevel": "xhigh"
   }

3. Run a session that triggers a tool-heavy turn (e.g., read/write/edit batch, ~14k thinking tokens). No manual abort.
4. Observe request log: turn emits thinking then 1-3 tool calls, last tool args truncated mid-token (cd ~/code/zosmaai/z-like), then proxy yields:

   [openai-chat] stream-truncated { finishReason: null, hadUsage: false, pendingToolCalls: 2 }
   error: upstream stream ended mid tool call without a terminal signal — possible truncation
   

5. Reproduction matrix (same as anomalyco/opencode#40888 for gpt-5.6-luna through same opencode Go endpoint):
   • stream:true + tools → fails with upstream stream ended mid tool call...
   • stream:false + tools → works (buffered, reframed as SSE)
   • stream:true + no tools → works
6. Frequency via Codex App → ocx → opencode-go/muse-spark-1.2: ~30-50% of tool turns with xhigh. Pi direct (no ocx) not observed. Other models via same proxy (opencode-go/kimi-k2.7-code, qwen3.8-max) rarely hit it.

Why this model hits it a lot:

• Reasoning budget vs output cap: muse-spark-1.2 defaults to extended thinking (budgetTokens: min(16000, limit.output/2)). opencode Go caps OUTPUT_TOKEN_MAX=32000 (see opencode#18108). Turns that spend 13-16k thinking + a 30-40KB write JSON hit finishReason: length mid-tool-call. See opencode#18108 repros: reasoning ~130k, output 32000, finish: "length", text_len=0.
• Known bridge shape: zosmaai/zosma-cowork#329 (mimo-v2.5 via opencode-go → 3 bash pending running) and opencode#26170 (finishReason: "other" with 0 output) show same orphaned-running-tool pattern behind opencode-go.

Version

2.26.0

Operating system

macOS 15.7.9 (Build 24G830), Darwin 24.6.0 arm64

Provider and model

opencode-go / muse-spark-1.2 (Pi alias muse-spark-1.2-contributor, PI_REASONING_LEVEL=xhigh, adapter openai-chat, baseUrl: https://opencode.ai/zen/go/v1, authMode: key)

Logs or error output

[openai-chat] stream-truncated { finishReason: null, hadUsage: false, pendingToolCalls: 2 }
error: upstream stream ended mid tool call without a terminal signal — possible truncation

No finish_reason, no [DONE], 2 pending tool calls (last JSON truncated mid-key). Same as opencode#40888 observed response.created then HTTP 502 / stream termination during tool call.

Screenshots and supporting files

No screenshots — error is in proxy log / SSE stream. Can provide curl SSE capture or ocx --debug trace on request.

Redacted configuration

{
  "port": 10100,
  "providers": {
    "opencode-go": {
      "adapter": "openai-chat",
      "baseUrl": "https://opencode.ai/zen/go/v1",
      "authMode": "key"
    }
  }
}

Catalog entry (~/.opencodex/catalog-backup.json):

{ "slug": "muse-spark-1.2", "provider": "opencode-go" }

Related upstream reports (same error family):

• anomalyco/opencode#40888 — exact same string, stream:false workaround works
• anomalyco/opencode#18108 — finishReason: length doom loop, OUTPUT_TOKEN_MAX=32000
• anomalyco/opencode#26170 / #26177 / #13102 — truncated tool variants
• zosmaai/zosma-cowork#329 — mimo-v2.5 via opencode-go orphaned running
• can1357/oh-my-pi#5600 / earendil-works/pi#4433 / pi#6019 / pi#6133

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[coderabbitai]

🔗 Related PRs

#2155 - fix(openai-chat): tolerate non-string padding repeats on resolved stream tool calls [open]
#2127 - fix(google): preserve and replay thought signatures across stream chunks and multi-tool turns (#2125) [open]
#2112 - fix(catalog): allow per-provider/model opt-out of code_mode_only tool mode (#2106) [merged]
#2145 - fix(responses): bridge routed tool_search through the Responses passthrough [open]
#2150 - fix(google): preserve and replay thought signatures across stream chunks [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

I verified the exact current parser path. The reported message is an intentional fail-closed guard: it is emitted only after the upstream body reaches EOF while at least one tool call is still buffered and no Chat finish_reason / [DONE] terminal was observed. OpenCodex must not flush the partial JSON as an executable tool call.

The current evidence establishes a real failed turn, but it does not yet establish which component owns the truncation. response.created is not a Chat Completions terminal, while this provider/model currently uses the openai-chat adapter. PR #2155 is separate: it handles malformed non-string padding on continuation deltas and does not repair a genuine EOF with partial tool arguments.

Before adding a model-scoped stream:false compatibility path, please attach one redacted raw upstream capture from the exact OpenCodex request, including:

• the final 10 SSE events/frames before disconnect,
• the exact upstream path and the model, stream, and tool-related request fields,
• whether any Chat finish_reason, [DONE], Responses response.completed / response.incomplete, or structured error frame appears,
• and the terminal shape from the same request with stream:false.

If the socket truly closes mid-JSON, this is an upstream streaming defect and the safe OpenCodex workaround is a narrowly evidence-backed buffered bridge for the affected provider/model. If a terminal frame exists in a different wire shape, the correct fix is in the parser instead. I am keeping this open as needs-info rather than guessing between those two incompatible fixes.

[lidge-jun]

리뷰 · 우선순위 68 / 80

실화임. 지금 openai-chat.ts 1727줄이 finishReason 없고 pendingToolCalls 있으면 바로 upstream stream ended mid tool call without a terminal signal — possible truncation 냄. muse-spark-1.2가 opencode.ai/zen/go/v1에서 툴 델타만 주고 스트림을 닫음. finish_reason/[DONE]/response.completed 없음. args가 cd ~/code/zosmaai/z처럼 잘림. Pi direct는 됨. ocx 프록시만. stream:true + tools만 죽음. 2.26.0에서 30-50%.

#2155 패딩이랑 다른 구멍임. 그건 non-string 반복. 이건 종단 시그널. 같이 넣어도 이 400은 안 죽음. 어댑터가 중간 JSON을 에러로 올려서 클라이언트가 재시도/버퍼 폴백을 못 함. OpenCode #40888이 stream:false로 우회한 바로 그 매트릭스임.

2.27은 이미 나갔음. 2.28 후보임. types.ts/config.ts 안 건드리는 버그임. 분할이랑 무관.

점수는 68임. 실사용 툴턴이 반타작임. #2137 bearer보다 체감은 이쪽일 수 있음. 드래프트 #2155를 이걸로 닫지 말 것.

해결방안: 게이트웨이가 툴+스트림에서 자주 끊기면 그 프로바이더만 버퍼 폴백 (stream:false 후 SSE 재포장). 아니면 잘린 args를 에러 대신 재시도 가능하게. 전역으로 finish 없는 툴콜을 성공 처리하면 #1531 fail-closed가 무너짐. 재현은 opencode-go + muse-spark-1.2 + xhigh 툴 배치.

이 댓글은 grok-bot이 작성했습니다

[Vontean]

Independent reproduction (opencodex 2.24.0, Codex App -> ocx -> opencode-go, muse-spark-1.2-contributor @ xhigh): 22/22 tool turns failed today, 502/503, same error string.

Additional raw-wire evidence against https://opencode.ai/zen/go/v1 (from our setup):

• BOTH muse-spark-1.2 and muse-spark-1.2-contributor streaming SSE never sends [DONE] and never emits a real finish_reason (only null), with or without stream_options.include_usage and with or without reasoning_effort. The stream just ends after a usage chunk and a trailing {"choices":[],"cost":"0"} frame.
• Forcing tool_choice on the streamed path returns an empty assistant message with finish_reason:null (no tool_calls delta at all).
• The BUFFERED path is well-formed: stream:false + tools returns complete tool_calls JSON (verified).
• Sibling model deepseek-v4-flash on the SAME endpoint streams correctly (finish_reason:stop + [DONE]) -> the missing-terminal defect is scoped to the Muse backend relay behind the zen/go gateway, not the gateway as a whole.
• The standard OpenAI-compatible base /zen/v1 rejects these models (Model not supported), so /zen/go/v1 is the only accessible route for Muse today.

Status of latest: v2.27.0 still contains the identical fail-closed guard (src/adapters/openai-chat.ts:1734) and adds no tolerance/buffered-fallback option for openai-chat routed models. So this remains unfixed upstream.

Local workaround we validated A/B (not a PR, just reporting the direction in case it helps the fix): for an allowlisted model, force stream:false upstream and reframe the buffered JSON as SSE via the existing parseResponse (mirrors the anomalyco/opencode#40888 stream:false workaround). Without the allowlist knob the exact error reproduces; with it the same request completes with response.completed + a full function_call on 200.

[Vontean]

Independent reproduction (opencodex 2.24.0, Codex App -> ocx -> opencode-go, muse-spark-1.2-contributor @ xhigh): 22/22 tool turns failed today, 502/503, same error string.

Additional raw-wire evidence against https://opencode.ai/zen/go/v1 (from our setup):

• BOTH muse-spark-1.2 and muse-spark-1.2-contributor streaming SSE never sends [DONE] and never emits a real finish_reason (only null), with or without stream_options.include_usage and with or without reasoning_effort. The stream just ends after a usage chunk and a trailing {"choices":[],"cost":"0"} frame.
• Forcing tool_choice on the streamed path returns an empty assistant message with finish_reason:null (no tool_calls delta at all).
• The BUFFERED path is well-formed: stream:false + tools returns complete tool_calls JSON (verified).
• Sibling model deepseek-v4-flash on the SAME endpoint streams correctly (finish_reason:stop + [DONE]) -> the missing-terminal defect is scoped to the Muse backend relay behind the zen/go gateway, not the gateway as a whole.
• The standard OpenAI-compatible base /zen/v1 rejects these models (Model not supported), so /zen/go/v1 is the only accessible route for Muse today.

Status of latest: v2.27.0 still contains the identical fail-closed guard (src/adapters/openai-chat.ts:1734) and adds no tolerance/buffered-fallback option for openai-chat routed models. So this remains unfixed upstream.

Local workaround we validated A/B (not a PR, just reporting the direction in case it helps the fix): for an allowlisted model, force stream:false upstream and reframe the buffered JSON as SSE via the existing parseResponse (mirrors the anomalyco/opencode#40888 stream:false workaround). Without the allowlist knob the exact error reproduces; with it the same request completes with response.completed + a full function_call on 200.