providers: models.dev catalog yields no models for any provider except built-in opencode #51739

Summary

The models.dev catalog is not being applied to any provider. Only the built-in opencode provider exposes models; every other provider (google, groq, openrouter, vercel) reports Model unavailable, even with valid API keys and stored OAuth credentials. This makes the entire catalog — and every free-tier provider in it — unusable.

Environment

• opencode version: 2.0.18 (channel latest)
• OS: Microsoft Windows 11 Pro 10.0.26200.0 (win32 x64)
• Terminal: TERM=xterm-256color, no TERM_PROGRAM/COLORTERM/WT_SESSION (not a known terminal emulator)
• Shell: C:\Program Files\Git\bin\bash.exe (configured via "shell": "bash" in config)
• Install/channel: latest
• Active plugins: none configured

Reproduction

1. Set a valid provider API key as a User-scope environment variable (e.g. GEMINI_API_KEY for Google AI Studio). Confirm the key itself works: curl -H "x-goog-api-key: $GEMINI_API_KEY" "https://generativelanguage.googleapis.com/v1beta/models?pageSize=3" returns HTTP 200.
2. Start opencode: opencode (opencode service status reports the background service as healthy).
3. Run opencode models.
4. Run opencode run -m google/gemini-3.5-flash "Reply with exactly: OK".
5. Repeat with other providers, e.g. opencode run -m groq/openai/gpt-oss-120b "...", opencode run -m vercel/meta/llama-3.3-70b "...".

Expected Behavior

Step 3 should list models for every provider whose credential is present (google, groq, openrouter, vercel, …), and step 4/5 should produce a model response instead of an error.

Actual Behavior

Step 3 lists only opencode/* models (49 entries) — no other provider appears at all. Steps 4 and 5 fail with:

Error: Model unavailable: google/gemini-3.5-flash
Error: Model unavailable: groq/openai/gpt-oss-120b
Error: Model unavailable: vercel/meta/llama-3.3-70b

This includes providers that have a stored OAuth credential in the credential table (google, openrouter, vercel), so it is not an env-var/credential problem.

Additional Context

The catalog cache itself is intact and valid. Reading the kv table of opencode.db:

• Key models-dev:catalog holds {updatedAt, digest, body}.
• body parses as JSON and contains 223 providers (groq: 16 models, google: 39, openrouter: 384, mistral: 35, vercel: 388, nvidia: 105).
• The stored digest matches sha256(body), so the cache is not corrupted.
• updatedAt corresponds to a refresh performed by this same binary shortly before the investigation, and https://models.dev/api.json is reachable from this machine (HTTP 200).

Model IDs are valid. gemini-3.5-flash is present under google and openai/gpt-oss-120b under groq in that same catalog, so the failures are not typo'd identifiers.

Not caused by a stale background service. Starting a brand-new server process (opencode serve --port <p>) and connecting with opencode run --server http://127.0.0.1:<p> -m groq/openai/gpt-oss-120b reproduces the identical error.

Not caused by config-defined providers shadowing the catalog. Tried and ruled out:

• Native V2 providers entries with env, canonical, and settings.apiKey for google/groq/mistral/openrouter.
• Legacy V1 provider entries with options.apiKey.
• Removing all non-opencode provider entries from config entirely.

In all three cases opencode models continued to list only opencode/*, and google/* / groq/* stayed unavailable.

Other observations

• opencode auth login groq correctly recognises groq as a connectable integration but reports API key input requires an interactive terminal, so the CLI-only path to a stored credential is unavailable here.
• The server emits a V1→V2 normalization warning, configuration normalization diagnostic path=$.providers.google kind=conflict action="retained native value over legacy value", when both spellings are present. This looks expected, but is included for completeness.
• Unrelated, but possibly of interest: when a V1 (1.18.32) binary is first on PATH, running it against this V2 database fails with Database is not empty and has no session table. Two installations coexisting seems easy to end up with.

Workarounds tried

• Adding explicit env / canonical / settings.apiKey to providers — no effect.
• Removing config-defined providers so env-var discovery runs — no effect.
• Restarting the server (fresh process) — no effect.
• Using a separate MCP server that calls the free provider API directly — this works and is currently the only way to reach those models, but it is not a real fix.