Repository navigation
opencode: configured providers appear disconnected in model dialogs #49309
Description
Description
Custom providers from opencode.json are available and their models appear in /models, but the TUI treats them as disconnected when no authenticated integration exists.
In the model picker, models with the same name are shown without provider names, so they cannot be distinguished. In the integration picker, the configured providers also look unconfigured.
Why this happens
OpenCode uses two different kinds of provider state:
- A configured provider is enabled by
opencode.jsonand can provide models. - A connected integration has a saved credential or an available environment variable.
The server correctly makes configured providers available, but the TUI's useConnected() check only looks at integration connections. The model dialog then hides provider names whenever no integration has a connection. The integration dialog also uses the absence of a connection as if the provider was not configured at all.
Expected:
- Show the provider name beside each model.
- Clearly mark custom providers from the config as configured.
- Keep configured and authenticated states distinct.
Actual:
- Models with the same name look identical.
- Configured providers look disconnected.
Plugins
None
OpenCode version
2.0.4
Steps to reproduce
- Disconnect all authenticated providers.
- Create
opencode.jsonwith:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"byok-one": {
"npm": "@ai-sdk/openai",
"name": "BYOK One",
"options": {
"baseURL": "https://example.com/v1",
"apiKey": ""
},
"models": {
"test-model": {
"name": "Same Model"
}
}
},
"byok-two": {
"npm": "@ai-sdk/openai",
"name": "BYOK Two",
"options": {
"baseURL": "https://example.com/v1",
"apiKey": ""
},
"models": {
"test-model": {
"name": "Same Model"
}
}
}
}
}- Run
opencode --standalone. - Open
/modelsand search forSame Model. - Notice that both results have the same label and no provider name.
- Press
Ctrl+Aand notice that the BYOK providers do not appear configured.
This reproduces consistently.
Screenshot and/or share link
Model List (no differentiation between custom providers)
Integration List (doesnt show custom ones as connected)
Operating System
macOS (Darwin 27.0.0, arm64)
Terminal
Zed
Activity
github-actions commentedon Sep 16, 2026
This issue might be a duplicate of existing issues. Please check:
Ivony commentedon Oct 14, 2026
Adding one angle that I think makes this more than a cosmetic gap.
The gate counts saved integration connections, not configured providers:
(2.0.28; the same function is
ziin 2.0.11 per the notes above andejin 2.0.27 — logic unchanged across all three.)Providers declared in
opencode.jsonunderproviders.<id>with inlinesettings.apiKey— the documented custom-provider / gateway recipe, and the only way to add a self-hosted gateway — do appear in/api/integration, but always withconnections: []. Declaring them creates no connection.The consequence is that the number of configured providers and models does not move the gate at all. A setup made up entirely of self-hosted gateways computes
some(...) === falsepermanently, no matter how many gateways or models there are:So for a user who only ever runs self-hosted models, the picker never groups and never shows provider names. Nothing they do on the configuration side changes that; they have to separately complete a
/connect(or environment-credential) flow against some models.dev catalog provider.That requirement is the part I'd call a real defect rather than a rough edge: the docs route custom/self-hosted gateways through configuration and never mention
/connect, while/connectandauthmanage integration accounts for catalog providers. Following the documented path for a self-hosted gateway therefore guarantees the gate stays false — and a user whose whole setup is self-hosted may have no catalog provider to connect in the first place.Worth noting the server data is already correct here: the configured providers are present and enabled, they just are not counted by the gate. So this is purely about which piece of state the TUI consults.