Skip to content

[FEATURE]: Interactive custom provider registration flow in /connect command palette #49091

Open

Description

@XXLxhPLMM

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/models is 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:

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/models endpoint is part of the OpenAI API spec and supported by most compatible providers
  • The config should use @ai-sdk/openai-compatible as 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

  1. XXLxhPLMM commented on Sep 15, 2026

    @XXLxhPLMM
    Author

    Closing in favor of reopening #48935 with the correct template format.

  2. yuhp commented on Oct 11, 2026

    @yuhp

    We have implemented a related plugin-side solution in opencode-models-discovery v1.10.0.

    For an OpenCode v2 provider that is already declared in opencode.json, the plugin can now use credentials managed by the native /connect flow through the host Integration API. This allows users to omit settings.apiKey from 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 of opencode.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-console after 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.

  3. tttrove commented on Oct 12, 2026

    @tttrove

    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

  4. opencodejr commented on Oct 28, 2026

    @opencodejr

    Thanks for the detailed proposal! You're asking for a guided /connect flow 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 editing opencode.jsonc by hand.

    Maintainers will consider it. Related issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions