Repository navigation
providers: custom and plugin-added providers never become available #53912
Description
Activity
Thanks for the detailed report and for the workaround. I think this is a duplicate of #42856: a
providersentry with a non-catalog id gets parsed (it shows in/api/config) but never reaches/api/provideror/api/model, sorun --modelfails withModel unavailable. The plugineditor.addpath you describe is already reported in #51802.Possible duplicates and related issues, ordered from most to least likely:
- opencode2: user-defined local provider models never enter the model catalog #42856: user-defined OpenAI-compatible provider is parsed but never enters the catalog;
Model unavailable, missing from/api/provider. Same steps and symptoms; comments confirm it on later 2.0.x releases on Windows. - providers: config-declared providers never materialize into registry (v2.0.15) #51285: config-declared providers never materialize into the registry. Same symptom on 2.0.15, also on Windows 10.0.19045, confirmed again on 2.0.21.
- v2.0.18: plugin ctx.provider.transform callbacks never execute — plugins cannot register providers (official docker image) #51802:
ctx.provider.transform/editor.addproviders never become available. This matches the plugin part of your report. - providers: custom provider silently skipped when model capabilities omit tools #49912: related. A config provider is silently dropped when model
capabilitiesis incomplete. That's a different cause, but it shows up the same way.
It would still help to add a comment on #42856 confirming that it happens on 2.0.24, along with your workaround (alias models under
opencodewith model-levelsettings.baseURLandbody.model). Others hitting this may find it useful.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
- opencode2: user-defined local provider models never enter the model catalog #42856: user-defined OpenAI-compatible provider is parsed but never enters the catalog;
Likely a duplicate — thanks for the pointers. Same root cause as #42856 (config-declared non-catalog provider never materializes) and #51802 (plugin
editor.addprovider never becomes available). Reproduced here on 2.0.24 (Windows 10 22H2), same symptoms.I added a confirming comment + a working workaround on #42856 (alias models under the active
opencodeprovider with model-levelsettings.baseURL+body.model). Happy to have this closed as a duplicate.Summary of what I observed on 2.0.24:
GET /api/provider/GET /api/modelreturn onlyopencodeandopencode-go.providers.<new_id>in config is parsed but never materialized; adding/overriding a model on a catalog provider viaprovidersdoes work.- Plugin
ctx.provider.transform->editor.addregisters the provider (visible inctx.provider.list()/ctx.model.list()) but it never becomes available;integrationID+ active credential,sourceConnection, andcanonicaldo not help. - Built-in LM Studio / vLLM discovery issues requests at their default ports but no active provider appears.
Summary
On OpenCode 2.0.24 a provider that is not in the built-in catalog can never be made available — neither via the
providersblock inopencode.json, nor from a plugin viactx.provider.transform->editor.add({ info, models }). The provider/models do appear in the plugin registry (ctx.provider.list()/ctx.model.list()), but they are absent fromGET /api/providerandGET /api/model, andopencode run --model <provider>/<model>fails withModel unavailable. This blocks using any custom/local OpenAI-compatible server (e.g. llama.cpp / llama-swap).Related observations:
providersis applied to catalog providers (adding a model toopencodeworks), but a new provider id is parsed (visible inGET /api/config) and never materialized.integrationIDpointing at a real integration with an active key credential,sourceConnection, andcanonicaldo not help.GET /api/v1/modelson127.0.0.1:1234; vLLMGET /health+GET /v1/modelson127.0.0.1:8000) but no active provider appears either.console.logdoes not reachopencode.log.Environment
@opencode/cli, npmlatest)TERM=xterm-256color,TERM_PROGRAM/COLORTERMunsetC:\WINDOWS\system32\cmd.exelocalai.discovery(global),opencode.models-disabler(global); nopluginsentry in configReproduction
Custom provider via config:
In the global
opencode.json(Windows:%USERPROFILE%\.config\opencode\opencode.json) add:{ "providers": { "acme": { "name": "Acme", "env": ["ACME_API_KEY"], "package": "@opencode/ai/providers/openai-compatible", "settings": { "baseURL": "https://llm.acme.example/v1" }, "models": { "qwen3-coder": { "name": "Qwen 3 Coder" } } } } }opencode service restartopencode api get /api/provider->acmeis absentopencode run --model acme/qwen3-coder "hi"->Error: Model unavailable: acme/qwen3-coderSame provider via a plugin:
~/.config/opencode/plugins/foo/index.js:Inside the plugin,
ctx.provider.list()showsacmeandctx.model.list()shows its model.opencode api get /api/providerstill lacksacme;opencode run --model acme/<model>->Model unavailable.Expected Behavior
Per the V2 docs (Providers -> Custom, and build/plugins ->
ctx.provider.transform/editor.add), a non-catalog provider with a validpackage,settings.baseURLand at least one model should become available and selectable, the same way catalog providers do.Actual Behavior
The provider stays inactive and its models are unselectable.
GET /api/providerreturns onlyopencodeandopencode-go(both haveintegrationID: "opencode"and an active OAuth credential).Additional Context
Things that DID work:
providers(e.g.providers.opencode.models.config-test-model->opencode/config-test-modelresolves).ctx.model.transform(editor => editor.update("opencode", alias, draft => ...)).Things that did NOT work:
providers(not even materialized).ctx.provider.transform->editor.add(registered but never active), including with an existingintegrationID+ active credential, withsourceConnection, and withcanonical.Workaround in use (confirms the catalog-provider path works): attach local models to the active
opencodeprovider as alias models withmodelIDset to a catalog model, model-levelsettings.baseURLpointing at the local server, andbody.modeloverriding the outgoing model name. This makesopencode/local-<model>selectable and functional.