BYOK providers with saved API-key credentials fail with SessionRunnerModel.ModelUnavailableError (v1.18.21) #47577

Summary

On v1.18.21 (Windows x64), every provider that authenticates via a stored "type": "api" credential in auth.json fails to run a prompt, throwing SessionRunnerModel.ModelUnavailableError: Model unavailable: <provider>/<model> — even though the credential itself is valid (confirmed by calling each provider's real API directly with the same key, which succeeds).

Providers that do not depend on auth.json (native free models, e.g. opencode/big-pickle, and providers that need no key, e.g. huggingface's public inference) work correctly and return real completions.

Reproduction

1. Store a valid API key for any provider via the normal auth flow (results in auth.json containing {"type":"api","key":"..."}).
2. POST /api/session with {"model":{"providerID":"<provider>","id":"<model>"}} — session is created successfully, GET /api/session/:id shows the correct model.
3. POST /api/session/:id/prompt with a simple text prompt — request is accepted (200, admitted into the queue).
4. Poll GET /api/session/:id/message — no assistant message ever appears. Server log shows:

   level=ERROR message="Failed to drain Session" cause="SessionRunnerModel.ModelUnavailableError: Model unavailable: <provider>/<model>"
   

Providers tested (all fail identically)

Groq, OpenRouter, Mistral, Cerebras, Chutes, Novita AI, NVIDIA, Google, Z.ai (zhipuai), Cloudflare Workers AI — 10/10 tested, each with a real key confirmed working against the provider's own API directly (e.g. curl https://api.groq.com/openai/v1/chat/completions with the same key succeeds; the OpenCode session for the same provider/model never completes).

Providers that work

• opencode/big-pickle (built-in free model, no auth.json entry)
• huggingface/<any model> (no auth.json entry — public inference)

Environment

• OpenCode v1.18.21, Windows x64, downloaded from the official GitHub release asset (opencode-windows-x64.zip)
• Server started via opencode serve --port <n> --hostname 127.0.0.1
• Confirmed on a freshly-recreated opencode serve process (ruled out stale-process/cache as the cause)
• auth.json credential shape: {"type":"api","key":"<valid key>"} (standard shape, same as used by opencode auth login)

What we ruled out

• Not a stale-process issue: restarted the server fresh, bug persists.
• Not an invalid-key issue: every key tested authenticates successfully against the provider's own API directly.
• Not a model-ID issue: tried multiple model IDs per provider, including ones taken directly from /provider's own catalog listing for that provider.
• Not a network/connectivity issue: the machine has normal internet access (confirmed against unrelated hosts), and providers that don't need auth.json work fine from the same process.

This suggests SessionRunnerModel.resolve() is failing to resolve/apply "type":"api" credentials from auth.json for third-party providers, even though the same auth.json is correctly used to populate /provider's connected list (which does show these providers as connected).

Happy to provide more logs/repro details if useful.