Repository navigation
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Add a complete, interactive provider registration flow in the TUI /connect command palette that lets users register any OpenAI-compatible provider end-to-end — entering an endpoint URL, optional API key, auto-discovering available models, and selecting which models to enable — all without manually editing opencode.jsonc.
Motivation
OpenCode has many built-in providers, but users frequently need to add self-hosted models (Ollama, vLLM, LocalAI), third-party platforms (DeepSeek, Qwen, Kimi), or corporate API gateways. Currently this requires manually editing opencode.jsonc with the correct npm package name, schema, and model capabilities — which is error-prone and not discoverable.
Proposed Flow
Step 1 — Endpoint
Provider endpoint URL: https://api.deepseek.com/v1
- Accept any URL (local or remote)
- Validate the URL is reachable
Step 2 — API Key (optional)
API key (leave empty for no auth): ****
- Optional because local providers (Ollama, LocalAI) typically don't need a key
- Some platforms return different model lists based on whether a key is provided
Step 3 — Auto-fetch Models
After entering endpoint + key, call the provider's /v1/models endpoint to discover available models:
Fetching models from https://api.deepseek.com/v1/models ...
Available models:
[x] deepseek-chat (context: 64000, output: 8000)
[x] deepseek-reasoner (context: 64000, output: 8000)
[ ] deepseek-v3 (context: 128000, output: 16000)
Select models to enable (space to toggle, enter to confirm):
- Pre-select all models, let user deselect unwanted ones
- Show model name and basic info when available
- Fall back to manual model name input if
/v1/modelsis not supported
Step 4 — Confirm & Save
Provider: deepseek
Endpoint: https://api.deepseek.com/v1
Models: deepseek-chat, deepseek-reasoner
Save to: [Global ~/.config/opencode/opencode.jsonc] / [Project .opencode/opencode.jsonc]
Confirm? (y/n)
Expected Config Output
{
"providers": {
"deepseek": {
"npm": "@ai-sdk/openai-compatible",
"options": {
"apiKey": "sk-xxx",
"baseURL": "https://api.deepseek.com/v1"
},
"models": {
"deepseek-chat": {
"name": "deepseek-chat",
"tool_call": true,
"limit": { "context": 64000, "output": 8000 }
}
}
}
}
}Relationship to Existing Issues
This request builds on and unifies several related issues:
- [FEATURE]: Add a textbox to set OpenAI compatible URL for local or remote custom connectors #44450 — Requests a URL textbox in
/connectfor custom connectors (Step 1) - Auto-discover models from OpenAI-compatible provider endpoints #6231 — Requests auto-discovery of models from OpenAI-compatible endpoints (Step 3)
- [FEATURE]: Feature Request: Add GUI Options to Edit Custom Providers and Manage Model Lists #33704 — Requests GUI options to edit custom providers and manage model lists
This proposal differs by providing a single, cohesive, step-by-step interactive flow in the TUI that covers the full lifecycle (endpoint → auth → model discovery → config generation → save), rather than isolated pieces. Ideally this could serve as the implementation plan that ties those three issues together.
Technical Notes
- The
/v1/modelsendpoint is part of the OpenAI API spec and supported by most compatible providers - The config should use
@ai-sdk/openai-compatibleas the default adapter, with future support for other adapters (@ai-sdk/anthropic,@ai-sdk/google) if the endpoint is detected - Consider supporting both global and project-level config save locations
Environment
- opencode version: 2.0.3
- OS: Windows_NT 10.0.26200 (win32 x64)
- Terminal: TUI mode
Activity
XXLxhPLMM commentedon Sep 15, 2026
Closing in favor of reopening #48935 with the correct template format.
yuhp commentedon Oct 11, 2026
We have implemented a related plugin-side solution in
opencode-models-discoveryv1.10.0.For an OpenCode v2 provider that is already declared in
opencode.json, the plugin can now use credentials managed by the native/connectflow through the host Integration API. This allows users to omitsettings.apiKeyfrom the provider configuration:{ "providers": { "gateway-custom": { "name": "Gateway Custom", "package": "@opencode-ai/ai/providers/openai-compatible", "settings": { "baseURL": "https://gateway.example.com/v1", "modelsDiscovery": { "enabled": true } } } } }After the provider is configured, users can run
/connect, select it, and enter the API key. The plugin uses the Integration credential for model discovery and runtime requests. The key is kept out ofopencode.json, discovery caches, diagnostics, and logs, and is attached to requests only in memory.This addresses the credential-management part of the proposed flow, but does not yet implement the complete interactive provider-registration experience requested here. The provider endpoint and package still need to be declared first; the plugin does not currently create a new provider definition from
/connect, save it to global or project configuration, or provide the full endpoint → model discovery → model selection → config-save flow.The plugin also provides interactive model discovery and cache management through
/models-discovery-consoleafter the provider has been configured.Related implementation and documentation:
This may be useful as an interim integration pattern while the native interactive registration flow is considered.
tttrove commentedon Oct 12, 2026
As someone coming from Cherry Studio, this is the one thing I miss: typing an endpoint + key into a small form and hitting "fetch models" to get everything working. Hand-editing opencode.jsonc for every new provider or gateway is the painful part. The proposed /connect flow — endpoint → optional key → auto-discover → pick models — would cover exactly that. +1
opencodejr commentedon Oct 28, 2026
Thanks for the detailed proposal! You're asking for a guided
/connectflow for any OpenAI-compatible provider. It would take the endpoint URL and an optional API key, discover models from/v1/models(with manual entry as a fallback), let you choose which models to enable, and save the result to global or project config, all without editingopencode.jsoncby hand.Maintainers will consider it. Related issues:
/connectfor custom connectors (closed)