providers: env-authenticated google/groq/openrouter models never resolve — "Model unavailable" #51737

Summary

On v2.0.18 every non-Zen provider (google, groq, openrouter) is absent from opencode models and from GET /api/model, and requesting one fails with Model unavailable: <provider>/<model> even though the API key is present in the environment, opencode auth list reports the provider as connected, and the cached models.dev catalog contains the model with full metadata. Only opencode/* models resolve.

Environment

• opencode version: 2.0.18 (npm @opencode/cli@2.0.18, running as the managed background service)
• OS: Windows 11 Pro, build 26200 (10.0.26200), x64
• Terminal: Git Bash on Windows (TERM=xterm-256color; no TERM_PROGRAM or COLORTERM)
• Shell: cmd.exe (%COMSPEC%); config sets "shell": "bash"
• Install/channel: latest (npm global at D:\opencode\npm-global), running as the managed background service
• Active plugins: opencode-openai-codex-auth, configured in ~/.config/opencode/opencode.jsonc (registry latest 4.4.0). It fails to load on every attempt with PluginModule.LoadError: Plugin must export a default definition with an id and an effect or setup function. (cause: SchemaError(Expected object at ["default"])) — 98 occurrences in the log. No local .opencode/plugin/ or .opencode/plugins/ files are involved in the failures below.

Reproduction

1. Set GEMINI_API_KEY and GROQ_API_KEY in the environment and sign in to OpenCode.
2. Confirm both providers are considered connected:

   opencode auth list
   # Google             Google                      stored
   # Google             GEMINI_API_KEY              environment
   # Groq               GROQ_API_KEY                environment
   

3. List models and observe that only opencode/* appears — 49 models, zero from any other provider:

   opencode models | sed 's|/.*||' | sort | uniq -c
   #     49 opencode
   

4. The same 49-only result comes from the running service's own catalog endpoint (GET /api/model, HTTP 200): every entry is an opencode/* id such as big-pickle, space-bunny-free, nemotron-3-ultra-free. No google/*, groq/*, or openrouter/* entry exists in the response.
5. Request a non-Zen model explicitly — it fails before any network call:

   opencode run -m google/gemini-3-flash "Reply with exactly: OK"
   # Error: Model unavailable: google/gemini-3-flash
   opencode run -m groq/openai/gpt-oss-120b "Reply with exactly: OK"
   # Error: Model unavailable: groq/openai/gpt-oss-120b
   

6. Control case in the same shell, same invocation — a Zen model succeeds:

   opencode run -m opencode/nemotron-3-ultra-free "Reply with exactly: OK"
   # > build · nemotron-3-ultra-free
   # OK
   

7. It is not the user config. Reproduce with a minimal config and a private server:

   echo '{ "model": "opencode/space-bunny-free" }' > repro.jsonc
   OPENCODE_CONFIG=./repro.jsonc opencode run --standalone -m google/gemini-2.5-flash "..."
   # Error: Model unavailable: google/gemini-2.5-flash
   OPENCODE_CONFIG=./repro.jsonc opencode run --standalone -m opencode/nemotron-3-ultra-free "..."
   # OK
   

Expected Behavior

opencode models and GET /api/model should list the google, groq, and openrouter models that the catalog already knows about and for which a key is available, and opencode run -m google/gemini-3-flash should reach the provider instead of failing at model resolution.

Actual Behavior

Non-Zen providers never enter the resolved model set. opencode models and GET /api/model return opencode/* only. Any non-Zen model fails with ModelUnavailableError: Model unavailable: <provider>/<model>, and the log shows the same for models that are demonstrably present in the cached catalog.

The catalog is not the problem. The cached models-dev:catalog row in ~/.local/share/opencode/opencode.db is current and complete:

updatedAt : 2026-09-27T23:28:39.506Z
digest    : 64c46645616953a380a1b26671dc82bbfced17d696438f9922de5ba982398359
providers : 223
google       -> models:  39 | env: GOOGLE_API_KEY,GOOGLE_GENERATIVE_AI_API_KEY,GEMINI_API_KEY
groq         -> models:  16 | env: GROQ_API_KEY
openrouter   -> models: 384 | env: OPENROUTER_API_KEY
opencode     -> models: 112 | env: OPENCODE_API_KEY

google/gemini-2.5-flash and groq/openai/gpt-oss-120b both resolve to populated entries, and the env var each provider declares is set. So resolution drops a provider that is catalogued and authenticated, while opencode — the one provider with a stored credential rather than an env var — survives.

The failure is consistent and silent: nothing warns that a connected provider was skipped. It surfaced only because the configured default model was google/gemini-3.5-flash, so every session died at the title step.

Additional Context

Log evidence (~/.local/share/opencode/log/opencode.log), 36 ModelUnavailableError entries across several service runs (run=f4dc6fd9, 6a89fef3, 44d28f78, 115a2717, 0395dce0), so it is not a single unlucky start:

17  Model unavailable: google/gemini-3.5-flash
 9  Model unavailable: groq/openai/gpt-oss-120b
 2  Model unavailable: openrouter/google/gemini-2.0-flash-exp
 2  Model unavailable: google/gemini-3.5-flash-lite
 2  Model unavailable: google/gemini-3-flash
 1  Model unavailable: google/gemini-flash-latest
 1  Model unavailable: vercel/meta/llama-3.3-70b

• Affected providers are exactly those authenticated from the environment; the opencode provider, authenticated from a stored credential, works. Worth checking whether env-sourced credentials are wired into catalog resolution differently from stored ones.
• Timing does not match the known partial-catalog window in fix(server): await catalog readiness for model and provider reads #36117 / server: plugin-contributed providers and models load asynchronously, and catalog reads expose partial generations as authoritative #51703: the catalog here is fully populated on disk and the failure persists across many service runs and restarts over hours, rather than clearing after warm-up.
• The two symptoms may share one cause, which is why the plugin error is included here instead of being split into a separate report. opencode-openai-codex-auth never loads (PluginModule.LoadError, 98 log occurrences). If a plugin that fails to load aborts the remaining catalog/provider registration, that would explain both at once.
• Workaround in place: default and title models are now opencode/space-bunny-free and opencode/nemotron-3.5-lightning-free, so the session is usable. Non-Zen providers remain unusable.