bug(runtime): OpenCode Go Muse Spark is routed to Chat Completions instead of Responses

[uzqw]

What happened

Using muse-spark-1.2-contributor through the opencode-go connection fails with:

Provider stream ended without finishing (other)

The model produces output, but Maka sends it through the Chat Completions endpoint. That endpoint does not provide a reliable terminal finish_reason for this model, so Maka correctly treats the resulting ambiguous EOF as a truncated stream.

Expected: this provider/model pair should use the OpenAI Responses API, where the gateway provides an explicit terminal response event and the turn can complete without weakening stream-safety checks.

How to reproduce

From a built Maka checkout, using a sandboxed configuration:

repo=/path/to/maka
sb=$(mktemp -d /tmp/maka-iso-XXXX)
mkdir -p "$sb/config/Maka/workspaces/default"
cp ~/.config/Maka/workspaces/default/{connection-catalog.json,credential-vault.json} \
  "$sb/config/Maka/workspaces/default/"

(
  cd "$sb"
  XDG_CONFIG_HOME="$sb/config" \
    node "$repo/packages/cli/dist/cli.js" run "Introduce yourself" \
      --connection opencode-go \
      --model muse-spark-1.2-contributor \
      --max-steps 5 \
      --yolo
)

Observed:

maka run: Provider stream ended without finishing (other)

A direct request to:

https://opencode.ai/zen/go/v1/chat/completions

returns content and usage but no reliable terminal finish_reason.

Routing the same provider/model pair through:

https://opencode.ai/zen/go/v1/responses

completes successfully, including a live tool-call turn.

Corrected diagnosis

The original diagnosis assumed that the AI SDK's emitted finish event proved that the provider had sent [DONE]. Review of the installed SDK showed that this assumption was incorrect:

• @ai-sdk/provider-utils discards the [DONE] sentinel.
• @ai-sdk/openai-compatible synthesizes a finish event from flush() on any ordinary response-body EOF.

Consequently, Maka cannot distinguish a real [DONE] from a bare EOF at the settlement layer. Relaxing the finish-reason check there could accept truncated text or authorize a truncated tool call.

The root cause is instead protocol routing: the model resolves to the native OpenAI adapter, but Maka defaults it to Chat Completions rather than Responses.

Scope

The reproduced affected pair is:

opencode-go/muse-spark-1.2-contributor

Maka's current OpenCode Go catalog exposes no other Muse model. Other OpenCode providers and similarly named models use separate provider contracts and are not changed without corresponding evidence.

A sweep of the 29 models exposed by the OpenCode Go gateway found this to be the only selectable model with the reported missing-finish_reason behavior; 23 models completed normally and 4 were unavailable upstream.

Related implementation

The same model-specific routing correction was independently merged in can1357/oh-my-pi#8980, which routes the OpenCode Go Muse Spark IDs through the Responses API instead of making the Chat Completions parser lenient.

Environment

• Provider: opencode-go
• Model: muse-spark-1.2-contributor
• Surface: CLI (maka run)
• OS: Manjaro Linux
• Node.js: v26.7.0

AI assistance

Initial investigation used Claude Code. The corrected diagnosis, final implementation, tests, and live verification used OpenAI Codex.