Repository navigation
Zen lists muse-spark-1.3-contributor-free, but OpenCode 1.18.27 omits it and invocation returns UnknownError #47120
Description
Description
OpenCode Zen advertises muse-spark-1.3-contributor-free through the authenticated model endpoint, but the current OpenCode CLI both omits it from discovery and receives a server-side error when the documented model ID is invoked.
This is related to the provider-catalog work in #40524, but the failed request below needs Zen-side investigation too.
Environment
- Windows 11
- OpenCode CLI 1.18.27
- Authenticated OpenCode Zen credential
- No plugins involved
- The active Zen profile has no explicit
modelormodelsmapping
Verified facts
-
GET https://opencode.ai/zen/v1/modelssucceeds with the authenticated Zen credential and includes:muse-spark-1.3-contributor-freemuse-spark-1.2-contributor-free
-
The official Zen documentation names the same model ID and labels it as available: https://dev.opencode.ai/docs/zen
-
opencode models --refreshsucceeds, but omitsopencode/muse-spark-1.3-contributor-freefrom the local picker/catalog. -
A minimal invocation with no project or user data fails:
opencode run --model opencode/muse-spark-1.3-contributor-free "Reply with exactly: MUSE13_OK"
Result:
UnknownError
Unexpected server error. Check server logs for details.
ref: err_20d48c32
Expected behavior
A model returned by the authenticated Zen /v1/models endpoint should be discoverable without a manual local model entry and should accept a minimal request, or return a specific actionable availability/policy error.
Actual behavior
The client catalog is missing an API-advertised, workspace-enabled model, and the exact documented model ID reaches Zen but returns an opaque server error.
Requested fixes
- Reconcile the
opencodeprovider picker with the authenticated Zen model endpoint as described in V2: Reconcile provider catalogs with /models endpoints #40524. - Investigate the Zen request identified by
err_20d48c32formuse-spark-1.3-contributor-free. - Add an integration regression test: a model returned by Zen discovery is selectable and accepts a minimal inference request.
Activity
pawel-adamczyk commentedon Sep 3, 2026
Follow-up: the Zen model itself is healthy; the failure is client-side catalog/metadata integration.
Using the same stored Zen credential, a minimal direct request to the documented endpoint succeeded:
The response had an ID and contained
MUSE13_OK.Therefore the account/workspace authorization and the upstream Muse 1.3 service are working. The
UnknownErrorfromopencode run --model opencode/muse-spark-1.3-contributor-free ...is not an upstream availability failure; it is consistent with the client failing to discover the endpoint-only model and consequently selecting/building the wrong request metadata or route.This strengthens the requested regression: resolve model metadata from authenticated Zen discovery, then verify that a model returned by discovery can execute through the stock OpenCode client path without any manual
provider.modelsentry.github-actions commentedon Sep 3, 2026
This issue might be a duplicate of or closely related to existing issues. Please check:
opencode run -mwith an unqualified model id returnsUnknownErrorafter session start (same opaque error, possibly related root cause)opencode runreturns {UnknownError} when the configured default model is deprecated #46760:opencode runreturnsUnknownErrorwhen the configured default model is unavailable/deprecated (same error presentation)The catalog-reconciliation half of this issue is already tracked in #40524. If your
UnknownError(referr_20d48c32) is distinct from the above, the server-side ref should help maintainers correlate it directly.pawel-adamczyk commentedon Sep 3, 2026
Additional root-cause evidence from OpenCode Desktop on Windows:
When the model is surfaced through an empty
provider.opencode.models["muse-spark-1.3-contributor-free"]entry, Desktop logs that it selectedOpenAICompatibleChatLanguageModeland then retriesInternal server error.That is the wrong transport for this Zen model. The catalog metadata identifies the model package as
@ai-sdk/openai, and the Zen documentation specifies the Responses endpoint. A direct minimal request to/zen/v1/responsessucceeds with the same credential.So discovery cannot merge endpoint IDs as empty model entries: it must also retain or derive the per-model SDK/transport metadata. Otherwise a missing catalog entry becomes both a picker omission and a runtime misrouting bug.
kabishou11 commentedon Sep 4, 2026
I'd like to work on this.
Plan: keep authenticated Zen
/v1/modelsdiscoveries from collapsing into emptyprovider.modelsentries that lose SDK/transport metadata (so the client misroutes away from Responses). Add a regression that a discovery-returned model stays runnable on the stock client path without a manual models map.Please assign if this is still open.
russrapper15-png commentedon Sep 4, 2026
https://inknaija.com/join?ref=INK-RUSSRAPP-8ZG8AGhttps://youtube.com/@grokmediaai
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊