Repository navigation
desktop: custom providers rejected as unavailable on this server #51330
Description
Description
On OpenCode Desktop v2.0.16 (Windows), saving a Custom OpenAI-compatible provider from the GUI always fails, so no custom API provider can be added. Same failure as #50650, and matches the v2-protocol block described in #51031.
Environment
- OpenCode Desktop 2.0.16 (Windows desktop build, not terminal/CLI)
- Windows 11 (10.0.26200.9457)
- No terminal involved (Desktop Electron app)
Steps to reproduce
- Open OpenCode Desktop → Settings → Providers → connect provider.
- Choose the custom OpenAI-compatible provider option.
- Fill in all the details (id, name, base URL, key, model id, etc.).
- Click Submit/Connect.
- A toast shows
Request Failed — Custom Providers are unavailable on this serverand closes automatically. Nothing is saved, so no custom provider is usable.
Screenshot
Screenshot of error while adding custom OpenAI-compatible provider:
Reacted by Aravya Singh, AI Agent Tip Line, Pavel Vaněček and Jonas Zürcher
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Sep 25, 2026
Thanks for updating the issue with the required description and reproduction details!
russrapper15-png commentedon Sep 25, 2026
AntonFrisk commentedon Sep 29, 2026
Same problem for me.
The CLI also does not have a Custom Provider option listen when using the /connect command.
Please fix!
PowerTokens commentedon Sep 30, 2026
Same here on Desktop 2.0.16 (Windows): filled in a custom OpenAI-compatible base URL and key, hit save, and got "Custom Providers unavailable".
/connectin the CLI doesn't list Custom either. Has anyone worked around it by editing the config file directly, or is it just disabled on Desktop for now?AntonFrisk commentedon Sep 30, 2026
The current solution is to go through the opencode.json and define by hand. Workde for me, on Windows.
You fav AI agent can do it for you
PowerTokens commentedon Oct 2, 2026
Thanks for confirming! Good to know the hand-written opencode.json route works on Windows too. Hopefully the desktop app picks up custom providers soon.
mohsen-niksirat commentedon Oct 19, 2026
Title: [Bug] Cannot add custom providers in v2 — plus Feature Request: multi-key per provider, key policies & visual node-based provider combos
Bug: Custom providers cannot be added (v2)
After upgrading to OpenCode v2, I can no longer add custom providers. Attempting to add a custom OpenAI-compatible provider (via opencode.json provider config and the provider settings UI) fails — the provider is either not saved, not listed in the model picker, or the config is silently ignored.
To reproduce:
This appears to be a regression from v1.x, where custom providers worked as documented. I see other users reporting the same issue (#51330).
Environment:
Feature Request: Multi-key, key policies, and visual provider combos
While I'm here, I'd like to request capabilities that would make OpenCode's provider layer best-in-class (9Router already does most of this and it's a game changer):
Multiple API keys per provider
Let users register any number of keys for the same provider (e.g. OPENAI_API_KEY_1, _2, _3...) and rotate between them automatically.
Per-provider key usage policies
Configurable selection strategy per provider, e.g.:
{
"provider": "openai",
"keys": ["sk-...", "sk-...", "sk-..."],
"key_policy": "round-robin" | "least-used" | "priority",
"cooldown_on_429": 60
}
Automatic failover to the next key on rate limits (429) would remove a huge pain point for heavy users.
Cross-provider combos (like 9Router's Smart Combos)
Allow chaining multiple providers/models into one virtual model with ordered fallback, e.g. my-stack = claude (subscription) → glm (cheap) → kimi (free), switching automatically on quota exhaustion or errors.
Visual node-based combo builder (UI)
A graphical, node-to-node editor (like 9Router's dashboard) where users can drag providers into chains, set priority order, and see live quota/usage per node. This would make the feature accessible to everyone, not just config-file power users.
Why this matters: many of us juggle multiple subscriptions, free tiers, and API keys across 3–5 providers. Today that requires running a separate proxy (LiteLLM / 9Router) just in front of OpenCode. Building this natively would remove that entire layer of complexity.
Thanks for the great tool — happy to help test.
neriousy commentedon Oct 20, 2026
Thanks for the report. We're tracking this same custom-provider save failure in #50650, so I'm closing this as a duplicate. Please follow that issue for updates.