Provider model catalogs are stale for OpenCode Go and OpenRouter

[iamwaqargulzar]

Tested with @deepseek-ai/dsh 0.1.1-rc.2 and the Open Design profile on Linux. The active DSH catalog exposed 16 OpenCode Go models while the authenticated provider /models endpoint returned 29. OpenRouter exposed 276 while its public /models endpoint returned 420; the static catalog also retained 11 IDs no longer returned live. Updating the nested compatible @earendil-works/pi-ai dependency from 0.82.1 to 0.84.2 improved this only partially (19 and 346 respectively).

The root behavior appears intentional but surprising: dsh-llm-pi-ai documents registerModelDiscovery as UI-only candidate discovery, not an active catalog refresh, so routes with omitted models remain pinned to the installed pi-ai snapshot.

A validated local workaround is to materialize the live IDs into each provider profile and explicitly state transport metadata so unknown-to-catalog IDs resolve:

llm-pi-ai:
  providers:
    opencode-go:
      apiKeyEnv: OPENCODE_GO_API_KEY
      api: openai-responses
      baseURL: https://opencode.ai/zen/go/v1
      models:
        # exact live /models IDs
    openrouter:
      apiKeyEnv: OPENROUTER_API_KEY
      api: openai-completions
      baseURL: https://openrouter.ai/api/v1
      models:
        # exact live /models IDs

After applying the exact live snapshots, dsh --profile open-design --models reports 29/29 OpenCode Go and 420/420 OpenRouter IDs, including gpt-5.6-luna, qwen3.8-max, muse-spark-1.2-contributor, google/gemini-3.7-flash, stealth/ox-alpha, and z-ai/glm-5.3.

Could DSH offer an opt-in live-catalog policy (with timeout/cache/stale fallback), or a supported refresh/adopt command, for OpenAI-compatible routes? That would retain configuration as the source of truth while avoiding silent catalog drift.

[SuperFurias]

i have the same issue, opencode go models autofetch is stale, there are many more models on opencode go

[SuperFurias]

and adding it manually doesn't work, as a custom provider, it auto fetches the models, yes, but opencode go, different models use different types of protocols. example: muse-spark-1.2-contributor uses openai responses, minimax-m3 uses anthropic messages, deepseek-v4-flash uses openai completions

[weijiafu14]

Your diagnosis matches what we see from the plugin side: registerModelDiscovery is UI-candidate discovery only, and routes declared with a static models list stay pinned to whatever the config shipped — nothing in that path re-reads the provider's live /models.

One measured datapoint for the other mechanism, since it is easy to miss that it already exists: a provider package (as opposed to a static settings declaration) runs real code at mount, so it can query the authenticated /models endpoint and register exactly what is live. We validated this today end to end on a stock @deepseek-ai/dsh@0.1.1-rc.2: the unmodified pi-provider-alibaba@1.0.1 package, running through pi2dsh (engine from npm, fresh DSH_HOME), cold-starts by fetching its live catalog, registers the models it actually got, and a real deepseek-v4-pro turn with tool calls completes over one of them; after a restart the routes are re-discovered rather than replayed from a stale snapshot. Evidence and the runnable setup: examples/alibaba-token-plan.

So the trade-off today is: static route declarations = pinned catalogs (your finding), package-registered providers = catalog is whatever the code fetched at mount. That is refresh-on-restart, not live refresh — a package could re-poll and re-register (the bridge follows directory changes hot), but none of the providers we validated does that today, so I won't claim it.

Scope note: this does not fix dsh-llm-pi-ai's static-route behavior you documented (OpenCode Go / OpenRouter through the official path will stay stale until upstream adds an active refresh); it is a workaround shape with different maintenance costs, offered as data for the design discussion.

[fan56]

dsh-model-sync addresses the staleness for pi.dev-listed routes, which covers both routes in this thread:

• OpenCode Go is a default route — measured today, pi.dev lists 24 models vs 16 in the installed catalog, so the sync brings in gpt-5.6-luna, grok-4.6, qwen3.8-max/flash, glm-5.3 and friends without any dsh / pi-ai upgrade.
• OpenRouter: pi.dev also lists openrouter, so declare the route as usual and add it to the sync scope; it stays fresh the same way:

model-sync:
  managedRoutes: [opencode-go, openrouter]

Writes go through the official settings.mutate seam (no patches), change-only per route, with an ETag/304 cache and last-good retention when the network flakes. Install:

npm i @aiwayds/dsh-model-sync
dsh plugin add @aiwayds/dsh-model-sync

Same scope note as above: this is a plugin-side freshness layer, not the upstream active-refresh design @weijiafu14 is proposing in #3752 — the two are complementary.

[sharathnirmala16]

I had recently started using DeepSeek Harness. Had the same issue of the models not being picked up for OpenCode Go. I asked it in Creator mode for it to see the simplest way to fix it. It was able to self diagnose and add the models, it hardcoded them in the YAML file. This was the steps it followed. I tested it out, and I am happy for now with the way it did it. I just have two sections, so the defaults aren't disrupted. I tried it with the new models like GLM 5.3 Flash and it works. The write up below was what it gave me:

Making All OpenCode Go Models Appear in the DSH Model Selector

---

Prerequisites

1. DSH installed with a provider configured in the user settings, e.g. ~/.dsh/settings.yaml containing:

   llm-pi-ai:
     providers:
       opencode-go:
         apiKeyEnv: OPENCODE_GO_API_KEY

2. The API key available to the harness — stored in ~/.dsh/.credentials.yaml (an entry named OPENCODE_GO_API_KEY under refs:), or set as an environment variable.

---

Step 1 — Confirm how the model selector is populated

1. Read ~/.dsh/settings.yaml → note the llm-pi-ai.providers section. That is the provider-route configuration.
2. Read the adapter docs at <DSH package dir>/@deepseek-ai/dsh-llm-pi-ai/README.md. Key facts:
   • Each provider route serves a model list that comes from either the installed pi-ai catalog or a models: list in settings — never from the live endpoint.
   • A models: list replaces the installed catalog for that route.
   • The selector (composer seat + /model popup) renders ctx.llm.listProviders() → ctx.llm.listModels(provider) — i.e. exactly what settings/catalog declare.
   • "The route's catalog never refreshes itself" — new models must be written into settings.
3. (Optional, deeper) The bundled catalog snapshot lives at <pi-ai package dir>/dist/providers/data/opencode-go.json — grouped by API protocol (anthropic-messages, openai-completions, openai-responses).

Step 2 — Fetch the live model roster from the endpoint

1. The OpenAI-compatible endpoint is https://opencode.ai/zen/go/v1 (from the catalog's baseURL for the openai-completions/openai-responses branches).

2. GET https://opencode.ai/zen/go/v1/models with Authorization: Bearer <key>. A minimal Node snippet (curl may fail on some sandboxed Windows shells with a schannel TLS error — Node's https works):

   const https = require('https');
   https.get('https://opencode.ai/zen/go/v1/models', {
     headers: { Authorization: 'Bearer ' + process.env.KEY, accept: 'application/json' },
   }, (res) => {
     let b = '';
     res.on('data', (c) => b += c);
     res.on('end', () => console.log(JSON.parse(b).data.map((m) => m.id).sort().join('\n')));
   });

   In the OpenCode TUI itself, /models shows the same list.

Step 3 — Diff live roster vs. installed catalog

1. Extract the catalog ids for opencode-go from the installed pi-ai version (16 at the time of writing): deepseek-v4-flash, deepseek-v4-pro, glm-5.1, glm-5.2, hy3, kimi-k2.6, kimi-k2.7-code, kimi-k3, mimo-v2.5, mimo-v2.5-pro, minimax-m2.7, qwen3.6-plus, minimax-m3, qwen3.7-max, qwen3.7-plus, grok-4.5.

2. Diff with the live list (34 at the time of writing) → the missing models are the ones to add. At the time of writing these were:

   deepseek-v4-flash-vision-exp, glm-5, glm-5.3, glm-5.3-flash, gpt-5.6-luna, grok-4.6, hy3-preview, hy4-preview, kimi-k2.5, longcat-2.0, mimo-v2-omni, mimo-v2-pro, minimax-m2.5, muse-spark-1.2-contributor, muse-spark-1.3-contributor, qwen3.5-plus, qwen3.8-flash, qwen3.8-max

Step 4 — Add the missing models to ~/.dsh/settings.yaml

1. Add a new provider route for the extras — some models are served only over the Responses API and must live on a second api: openai-responses route (see the example). Do not add a models: list to opencode-go — it would replace the catalog and force a single wire protocol onto a route whose models currently span three protocols:

   llm-pi-ai:
     providers:
       opencode-go:                       # leave untouched
         apiKeyEnv: OPENCODE_GO_API_KEY
       opencode-go-extras:                # CHAT-COMPLETIONS route
         apiKeyEnv: OPENCODE_GO_API_KEY
         displayName: OpenCode Go (extras)
         api: openai-completions
         baseURL: https://opencode.ai/zen/go/v1
         models:
           # Roster, capacities, modalities, and effort levels MUST be pulled from
           # https://models.opencode.ai/api.json (per-model reasoning_options,
           # modalities.input, limit.context/limit.output). Example entry:
           - id: glm-5.3
             name: GLM-5.3
             contextWindow: 1000000
             maxTokens: 131072
             reasoningEfforts:
               low: low
               high: high
               max: max
           # ... every model the gateway serves over chat completions ...
       opencode-go-responses:             # RESPONSES-only models get their own route
         apiKeyEnv: OPENCODE_GO_API_KEY
         displayName: OpenCode Go (responses)
         api: openai-responses
         baseURL: https://opencode.ai/zen/go/v1
         models:
           - id: gpt-5.6-luna
             name: GPT-5.6 Luna
             contextWindow: 1050000
             maxTokens: 128000
             input: [text, image]
             reasoningEfforts:
               off: none
               low: low
               medium: medium
               high: high
               xhigh: xhigh
               max: max
           # ... every model the gateway serves only over Responses ...

2. Why this shape (from dsh-llm-pi-ai source, resolveRouteModels):

   • A model id the catalog doesn't know needs a route-level api (request.api) or resolution fails with "model '…' needs an api".

   • A hand-declared route needs api + baseURL + a non-empty models list.

   • Gotcha — extra models default to text-only input. Models the catalog doesn't describe resolve their input modalities as entry input → catalog input → route defaultInput (default [text]), so the harness refuses attached images before sending ("this model doesn't support images") even when the model is vision-capable. Fix per model:

     - id: glm-5.3-flash
       input: [text, image]

     Or set a route-wide defaultInput: [text, image] — but that over-claims for every model on the route, and an image the provider then rejects fails mid-turn, so declare per model when you know them.

   • Same for reasoning — extras expose no effort menu until reasoningEfforts is declared. A hand-declared model has no catalog reasoning metadata, so it resolves as non-reasoning and the selector shows no effort levels. And the levels differ per model — there is no universal set: pi-ai's shipped OpenCode Go catalog carries a per-model thinkingLevelMap for many models (e.g. deepseek-v4-flash = high/max only, glm-5.2 = off/high/max, hy3 = off:"none"/low/high, grok-4.5 = low/medium/high, kimi-k3 = max only), and the OpenAI catalog gives gpt-5.6-luna the full low/medium/high/xhigh/max. So take each model's effort list from its reasoning_options in https://models.opencode.ai/api.json (the opencode-go section is the exact subscription roster): a none value maps to off: none, a toggle option means reasoning can be switched on/off but carries no effort levels, and a model with no effort option gets no reasoningEfforts block at all — inventing one overstates the model. Example:

     - id: grok-4.6
       reasoningEfforts:
         low: low
         medium: medium
         high: high

     Mechanics: keys are pi-ai's level set (off / minimal / low / medium / high / xhigh / max), only declared keys are offered, values are the wire spellings (identity values send reasoning_effort: <level> on the OpenAI-compatible route, off: with no value sends nothing, off: none sends reasoning_effort: none); a model with no off key offers no Off. Undeclared levels are pinned unsupported rather than guessed. To verify an unlisted model, check the opencode client's own model list (/models in the TUI) or the gateway's per-model pages.

   • Unknown ids get fallback capacities contextWindow: 262144 / maxTokens: 32768; add contextWindow: / maxTokens: per entry to tune, and reasoningEfforts: (e.g. off: / high: high) to expose an effort menu.

   • Where do name, contextWindow, maxTokens, input, and the effort levels come from? The authoritative source is https://models.opencode.ai/api.json — the registry the OpenCode clients themselves use, with per-model reasoning_options (effort values, including none, xhigh, max, and toggle types), modalities.input, and limit.context / limit.output. The gateway's /models endpoint discloses ids only; vendor docs and pi-ai's other provider catalogs are secondary and often stale. name is cosmetic; valid input values are text and image; maxTokens is the default output cap requests carry when none is named.

Step 5 — Validate

1. Re-read the file to confirm it's well-formed YAML.
2. Parse it (e.g. with js-yaml) and assert: the provider routes are present; model ids are unique and match the live endpoint's ids exactly (a typo'd id silently serves nothing / errors at request time).
3. Check the rules are satisfied: api ∈ supported protocols (openai-completions ✓), non-empty models, no duplicates.

Step 6 — See it in the GUI

1. Refresh the page (or reopen the model picker — it re-fetches from the host on open).
2. The selector now shows three groups: OpenCode Go (16 catalog models, untouched), OpenCode Go (extras) (chat-completions models), and OpenCode Go (responses) (Responses-only models), all served over the same credential.
3. No restart needed — the adapter re-reads settings per operation.

---

References (for verifying roster & capacities)

• OpenCode Models registry — authoritative per-model data (reasoning_options, modalities, limits)
• OpenCode Go — subscription and docs
• Z.AI GLM-5.3-Flash — GLM-5.3 / GLM-5.3-Flash capacities
• x.ai Grok models — Grok context window / image input
• OpenRouter — model cards (e.g. qwen3.8-max, muse-spark contributors)
• LongCat-2.0 — context claims
• Hy3 Preview — Hunyuan 3 capacity

Key points to explain to others

• Protocol matters, and the gateway reports it misleadingly. Some go models are Responses-only (gpt-5.6-luna, grok-4.6, muse-spark-1.2/1.3-contributor): a chat-completions request against them returns a bare 500 Internal server error (or 401 "Model … is not supported for format oa-compat"), while POST /v1/responses returns 200 — which is why those models "work in opencode" (its client uses the Responses API). Classify any new model by probing both endpoints before assigning it to a route.

• The selector is a declaration, not a live query — "a route gains a model when someone writes one."

• Even the "Fetch available models" button in Settings → Models answers from the installed catalog for routes pi-ai ships (no network call); only hand-declared (non-catalog) routes are interrogated over the wire.

• Adding a models: list to opencode-go itself replaces its 16-model catalog, and since that route spans three protocols, new unknown ids can't be added there without setting a route-level api (which repoints everything) — hence the separate opencode-go-extras route.

• A model whose id is never declared anywhere can still be sent directly (unchanged behavior), but it won't appear in the selector unless declared.