Repository navigation
V2 cold-start model resolution can select an unavailable catalog provider #62194
Description
This is a follow-up for the V2 cold-location behavior reproduced against the pinned fork commit 0ff0dfbca1f01765f6bd41d0379d9b97f1cf8d23.
Observed failure
On a fresh V2 location, the models.dev catalog can be populated before the provider integration registry has loaded. During that window catalog.available() treats a provider with no registered integration as available; with session.model unset, catalog.default() can choose the newest model in the bundled snapshot, even though its credentials and endpoint are absent. A reproduced cold first prompt selected nano-gpt / reflection/beam-1.0 and failed at transport. The same selection reproduced 3/3.
The V2 config reader also does not use the V1 OPENCODE_CONFIG / OPENCODE_CONFIG_CONTENT inputs and does not expand V1 {env:...} values. A provider configured only through those inputs is invisible to V2.
Expected behavior
- A provider backed only by a models.dev entry is not considered callable until its integration is positively registered, or V2 otherwise fails closed during initialization.
- V2 honors its documented global config path and literal values so an explicitly configured provider/model is visible to
/api/providerand session execution. - A session with an explicit model either runs that exact provider/model or returns a clear unavailable-model refusal; it never falls through to a different catalog model.
- Add cold-location tests where the catalog is already populated and provider integrations arrive later, including an explicitly configured proxy provider.
This is separate from swx-abbe's incremental chat-model-set follow-up. It does not ask for a big-bang catalog change; swx-abbe will add future models one at a time as they are approved.
Activity
opencodejr commentedon Nov 5, 2026
Thanks for the detailed write-up! Before we can look into it, we need a reproduction on a released upstream build. The commit you pinned (
0ff0dfbc…) is from a fork and isn't in this repository. On the currentdevbranch, both parts of the report look like they may already be handled:nano-gpt, shouldn't be picked as the default model.OPENCODE_CONFIG_CONTENT(with variable substitution), and the CLI passesOPENCODE_CONFIGthrough to the server.Could you please tell us, briefly and in your own words:
opencode --version. Does it still happen on the latest release (2.2.5)?session.modelor-mis set.You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.
These related issues might also be relevant (ordered by likelihood):
OPENCODE_CONFIG/OPENCODE_CONFIG_CONTENTOPENCODE_CONFIG_CONTENTthe only config sourcebrentyates-swx commentedon Nov 5, 2026
This was created in the upstream canonical repository by repository resolution. The requested follow-up belongs in the swxtchio/swx-opencode fork and is tracked at https://github.com/swxtchio/swx-opencode/issues/416.
opencodejr commentedon Nov 8, 2026
Closing this for now, since we haven't heard back. We asked for a reproduction on a released upstream build because the report was against a fork commit (
0ff0dfbc…) that isn't in this repository. On the currentdevbranch, models.dev providers without credentials aren't treated as available, andOPENCODE_CONFIG/OPENCODE_CONFIG_CONTENTare read, so we couldn't act on it as written.If you can reproduce this on an official release (e.g. 2.2.5), please comment with
opencode --version, your OS, how you installed OpenCode, a minimal config, the steps and the exact error, and we can reopen it. These related issues might also be useful: #34837, #36990 and #45492. Thanks!