Custom provider defaults to Chat Completions only, missing Anthropic / Response compatibility — some models undiscoverable

[whp233]

Description
Some models in custom providers default to openai-completions (Chat Completions) only, without Anthropic-compatible (anthropic-messages) and Response (openai-responses) endpoints. When a user configures a custom OpenCode Go provider, GET {baseURL}/models returns the full catalog, but DSH's discovery and routing filter by the provider's default protocol, so models served via anthropic-messages (e.g., qwen3.8-max / qwen3.8-flash / minimax-m2.5) and openai-responses (e.g., gpt-5.6-luna / muse-spark-1.2-contributor / grok-4.6) become undiscoverable, unaddable, and their reasoning toggle is unavailable.

Steps to Reproduce

1. Configure a custom provider in ~/.dsh/settings.yaml:

llm-pi-ai:
  providers:
    oc:
      api: openai-responses
      baseURL: https://opencode.ai/zen/go/v1
      apiKeyEnv: OC_API_KEY

2. In DSH Settings → Models, click “Fetch available models” for that provider
3. Observe candidates: only models matching the current api are returned; models on other protocols are missing

Expected Behavior

• Custom providers should expose discovery and routing for all three protocols, or at least auto-route by each model's own api field (anthropic-messages / openai-completions / openai-responses) when api is not explicitly set at provider level
• The built-in opencode-go frozen snapshot (pi-ai/dist/providers/data/opencode-go.json, 16 models) should be made dynamic or kept in sync to include new models like gpt-5.6-luna
• Considering the potential universality of this bug — any provider that simultaneously supports all three formats (Chat Completions / Anthropic / Response) may encounter the same issue — we suggest the maintainers also apply the same compatibility fix to other providers' selection and routing (auto-route by each model's api instead of filtering solely by the provider-level default protocol).

Actual Behavior

• Only Chat Completions models are discoverable; Anthropic / Response models are filtered out and not searchable
• Built-in opencode-go snapshot is stale (16 models, missing new ones) and the live GET /v1/models dynamic path is not reused

Workaround
Manually list models with explicit api per model:

models:
  - { id: gpt-5.6-luna, api: openai-responses }
  - { id: qwen3.8-max, api: anthropic-messages }

Environment
DSH 0.1.1-rc.2 / pi-ai 0.x / Windows 10 / https://opencode.ai/zen/go/v1 verified GET /v1/models returns 32 models (including the missing ones) and POST /v1/responses returns 200

[Astro-Han]

Also hitting this from the product side. PawWork (a DSH-based desktop app) ships OpenCode Zen's free models and had to adopt the documented workaround — the free set split across two route keys (opencode → openai-completions, opencode-responses → openai-responses) — because the gateway pins one wire protocol per model, and a model reached on the wrong endpoint answers a constant 500.

Two data points that may help scope the fix:

1. A reliable per-model discriminator already exists: models.dev's provider.npm field (absent → /chat/completions, @ai-sdk/openai → /responses). Our routing splits the free set by exactly that marker; free models marked @ai-sdk/anthropic / @ai-sdk/google are left unpublished rather than routed where they cannot answer.

2. The dispatch machinery is already in pi-ai: createProvider accepts an api map and dispatches on model.api ("A single api streams all models; an api map dispatches on model.api"), and resolveRouteModels already stamps a per-model api internally. What's missing upstream is only (a) an optional per-model api on profile models entries and (b) buildProvider passing a map instead of a single factory when a route's models resolve to mixed protocols. That would also close the discovery half of this report: the gateway's GET /v1/models listing is protocol-agnostic, so "Fetch available models" on a hand-declared route offers models the route can never serve — adoption is accepted, then every send fails with the constant 500 (same seam as Bug: "Fetch available models" returns stale bundled catalog for built-in providers (e.g. OpenRouter) instead of querying the live endpoint #4469/[Bug] llm.discoverModels returns build-time bundled catalog for known providers — newly released models (e.g. x-preview-f-free) never appear via "Fetch Models" #4564).

Cost of the two-route workaround for the record: two settings cards for one logical provider, and the declared route carries the "Custom" tag because its key isn't a catalog id. Happy to consolidate wire-level evidence if useful.

[argszero]

Verified all claims against 4e84901e64 (dsh 0.1.2-alpha.4) + pi-ai 0.84.4 (the version ^0.84.2 resolves). Astro-Han's analysis is accurate; I'll confirm it line-by-line, add two corrections to the OP's framing, and give the exact patch surface.

1. Confirmed: the two missing pieces are exactly (a) + (b)

• (a) — no per-model api on profile models entries. PiAiModelProfile (packages/llm/llm-pi-ai/src/catalog.ts:539-593) declares only id, name, contextWindow, maxTokens, input, reasoningEfforts, compat; the runtime schema mirrors it (packages/llm/llm-pi-ai/src/config.ts:306-309 modelFields). Materialization never reads an entry-level protocol: catalog.ts:853 resolves api = request.api ?? base?.api ?? routeApi (route → installed entry → shared route api).
• (b) — buildProvider passes a single factory, never a map. provider.ts:177-190 always calls createProvider({ ..., api: factory() }) with one PROTOCOLS[spec.api]. The docstring is explicit: "Every model on this path carries the route's protocol … So the route has a single API" (provider.ts:174-176).

2. Confirmed: pi-ai already supports the map form. CreateProviderOptions.api is ProviderStreams | Partial<Record<TApi, ProviderStreams>> — "Single implementation, or map keyed by model.api for mixed-API providers" (pi-ai 0.84.4 dist/models.d.ts:171-172), and "an api map dispatches on model.api, and a model whose api has no entry produces a stream error" (:175-178). So (b) is purely a harness-side change: build a map from the distinct apis of spec.models when they span more than one, keep the single factory otherwise.

3. Correction 1 — the OP's "workaround" is inert at alpha.4. Writing models: [{ id: gpt-5.6-luna, api: openai-responses }] does not do what it appears to. The schemastery object schema passes unknown keys through (the catalog even documents this at the modelOverrides boundary: "this guards the schema boundary, which passes unknown keys through"), so api survives parsing — but resolveRouteModels never reads it, and the model resolves to the route-level api. The workaround therefore gives false confidence: the entry is accepted, the model appears configured, and every send still hits the wrong endpoint. (This is presumably also why the two-route workaround — opencode / opencode-responses — is what PawWork actually shipped: it is the only thing that works today.) With (a) implemented, the OP's original config shape becomes the real fix: per-model api wins over the route's.

4. Correction 2 — the "stale snapshot" is a pi-ai version pin, not a harness data bug. The built-in catalog is getBuiltinModels from @earendil-works/pi-ai/providers/all (catalog.ts:15). pi-ai 0.84.4's providers/data/opencode-go.json already contains 25 models across all three protocols — anthropic-messages (minimax-m3, qwen3.8-flash), openai-completions (20), openai-responses (gpt-5.6-luna, grok-4.6, muse-spark-1.2-contributor). Every model the OP lists as missing is present. On 0.1.1-rc.2 the resolved pi-ai was older; a dependency bump (within the existing ^0.84.2 range) restores the catalog. A harness-side "make it dynamic" change is not needed for this half.

5. Scope precision — mixed-protocol catalog routes already work. A route whose key names an installed provider, with no api override, reuses the catalog provider (provider.ts:144-159 reuseCatalogProvider): getModels returns the route's materialized models and stream delegates to the catalog provider, which dispatches per model.api. So providers: { opencode-go: { apiKeyEnv: … } } serves all 25 models on their correct protocols today. The gap is confined to hand-declared routes (no catalog entry) and explicit route-level api overrides, where one protocol is forced onto every model.

Exact patch surface (each change is small and contained):

1. catalog.ts — add api?: string to PiAiModelProfile (documented as "wire protocol this model speaks; wins over the route's api; absent inherits the installed entry, then the route"); change catalog.ts:853 to const api = entry.api ?? request.api ?? base?.api ?? routeApi (per-model wins over route override).
2. config.ts — add api: z.union(supportedProtocols()) to modelFields (the profile-level union already exists at :317), so an unsupported protocol name is refused at the schema, consistent with the package's refuse-rather-than-skip style.
3. provider.ts — in buildProvider, collect the distinct apis of spec.models; if one, keep api: factory(); if several, pass api: Object.fromEntries(apis.map(a => [a, PROTOCOLS[a]])). Update the "single API" invariant comment to "dispatch per model.api". Note PROTOCOLS (:47-51) already covers exactly the three protocols pi-ai's map form needs, so no table growth.

One design note: with (a), the settings/directory surfaces that edit models entries will want to expose the field too — but that is follow-up surface, not a blocker for the config-level fix, which unblocks the OP's original single-route shape natively. If either of you open a PR for (a)+(b), I'll help verify the dispatch implications in the thread.