fix(opencode): route Muse Spark 1.2 models to OpenAI Responses API - #10874
Merged
diegosouzapw merged 2 commits intoAug 21, 2026
Merged
diegosouzapw merged 2 commits into
diegosouzapw merged 2 commits into
Conversation
OpenCode Zen serves muse-spark-1.2 and muse-spark-1.2-contributor-free ONLY on the Responses API endpoint (https://opencode.ai/zen/v1/responses), not /chat/completions. Without targetFormat:"openai-responses" they fall through to the default chat/completions pass-through and the upstream returns null/empty content (issue diegosouzapw#10867). Declaring them with targetFormat:"openai-responses" + supportsReasoning makes chatCore route them to /responses and forward reasoning_effort. The opencode provider is passthrough, so this only sets the wire format and capability flags — the live upstream model list already advertises both ids.
diegosouzapw
merged commit Aug 21, 2026
374b387
into
diegosouzapw:release/v3.8.50
0 of 3 checks passed
This was referenced Aug 21, 2026
maxmad64bis
added a commit
to maxmad64bis/OmniRoute
that referenced
this pull request
Aug 21, 2026
… alias
PROVIDER_MODELS is keyed by a provider's public alias (e.g. "oc"), not
its raw registry id ("opencode") -- OpencodeExecutor.execute() called
getModelTargetFormat() with the raw id, so it silently missed every
registry entry and fell back to "openai" for buildUrl()/buildHeaders(),
while chatCore's own (correctly aliased) request-body translation still
switched to the Responses API shape for targetFormat:"openai-responses"
models. Net effect: a Responses-shaped body got sent to the
/chat/completions URL, and upstream returned a degenerate empty response.
Surfaced live by diegosouzapw#10874, which added the first targetFormat:"openai-responses"
entries to the opencode provider's registry (oc/muse-spark-1.2 and
oc/muse-spark-1.2-contributor-free) -- no prior model in this registry
exercised this code path, so the alias mismatch was never triggered
before. Extracted the alias resolution into resolveOpencodeTargetFormat(),
mirroring chatCore/targetFormat.ts's own resolveChatCoreTargetFormat().
maxmad64bis
added a commit
to maxmad64bis/OmniRoute
that referenced
this pull request
Aug 21, 2026
… alias
PROVIDER_MODELS is keyed by a provider's public alias (e.g. "oc"), not
its raw registry id ("opencode") -- OpencodeExecutor.execute() called
getModelTargetFormat() with the raw id, so it silently missed every
registry entry and fell back to "openai" for buildUrl()/buildHeaders(),
while chatCore's own (correctly aliased) request-body translation still
switched to the Responses API shape for targetFormat:"openai-responses"
models. Net effect: a Responses-shaped body got sent to the
/chat/completions URL, and upstream returned a degenerate empty response.
Surfaced live by diegosouzapw#10874, which added the first targetFormat:"openai-responses"
entries to the opencode provider's registry (oc/muse-spark-1.2 and
oc/muse-spark-1.2-contributor-free) -- no prior model in this registry
exercised this code path, so the alias mismatch was never triggered
before. Extracted the alias resolution into resolveOpencodeTargetFormat(),
mirroring chatCore/targetFormat.ts's own resolveChatCoreTargetFormat().
This was referenced Aug 21, 2026
Merged
diegosouzapw
pushed a commit
that referenced
this pull request
Aug 21, 2026
… too (#11049) ⭐5 — Muse Spark responde só na Responses API; #10874 corrigiu só o provider `opencode`, mas `opencode-zen` (faltava targetFormat em 2 entries) e `opencode-go` (6 entries effort-tier) nunca receberam. Espelha a declaração. freebuff NÃO tocado (backend codebuff.com /chat/completions distinto, verificado). TDD 2/2 + 18/18 irmãos. Fecha #11048. Base-red #9985 inherited.
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
…iegosouzapw#10874) OpenCode Zen serves muse-spark-1.2 and muse-spark-1.2-contributor-free only on the OpenAI Responses API endpoint, not /chat/completions. Declares targetFormat: "openai-responses" for both so requests route correctly instead of returning null/empty content. Closes diegosouzapw#10867. Validated in an isolated worktree boarded onto origin/release/v3.8.50 (0 conflicts, 1 file): - Added a TDD regression test (tests/unit/opencode-muse-spark-responses-10867.test.ts) since the PR had none — confirmed RED against origin/release/v3.8.50 (entries absent) and GREEN on this branch, pushed fix-in-place. - check-file-size, check-changelog-integrity: OK. - typecheck:core: clean. - check-complexity / check-cognitive-complexity: OK, both under baseline. Co-authored-by: zoser69 <zoser69@users.noreply.github.com>
muhamadgalihsaputra
pushed a commit
to niyatna/NiyatnaRoute
that referenced
this pull request
Sep 27, 2026
… too (diegosouzapw#11049) ⭐5 — Muse Spark responde só na Responses API; diegosouzapw#10874 corrigiu só o provider `opencode`, mas `opencode-zen` (faltava targetFormat em 2 entries) e `opencode-go` (6 entries effort-tier) nunca receberam. Espelha a declaração. freebuff NÃO tocado (backend codebuff.com /chat/completions distinto, verificado). TDD 2/2 + 18/18 irmãos. Fecha diegosouzapw#11048. Base-red diegosouzapw#9985 inherited.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
OpenCode Zen serves
muse-spark-1.2andmuse-spark-1.2-contributor-freeonly on the OpenAI Responses API endpoint (https://opencode.ai/zen/v1/responses), not/chat/completions. This is confirmed in the official OpenCode Zen docs (https://opencode.ai/docs/zen/ — both model ids listhttps://opencode.ai/zen/v1/responsesas their endpoint).Without
targetFormat: "openai-responses"these models fall through to the default chat/completions pass-through and the upstream returnsnull/emptycontent(reported in #10867).Change
Declared both models in
open-sse/config/providers/registry/opencode/index.tswith:targetFormat: "openai-responses"(route to/responses)supportsReasoning: true(forwardreasoning_effort)The
opencodeprovider ispassthroughModels: true, so this only sets the wire format and capability flags — the live upstream model list already advertises both ids.Behavior notes
oc/muse-spark-1.2-contributor-freeresolves to the/responsesendpoint and returns realoutput_textinstead ofnull.reasoningitem for display. That is expected behavior, not a bug — this PR only fixes the endpoint routing so content is returned at all.Test plan
curl .../v1/models | grep muse-sparklistsoc/muse-spark-1.2andoc/muse-spark-1.2-contributor-free/v1/chat/completionswithoc/muse-spark-1.2-contributor-free→ non-null content returnedCloses #10867 (root-cause fix; the issue also discusses the hidden-thinking nuance).