Repository navigation
[FEATURE]: Feature Request: Add GUI Options to Edit Custom Providers and Manage Model Lists #33704
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
Problem Statement
Currently, managing custom providers (such as local inference engines like LM Studio or Jan AI) through the OpenCode UI is a destructive or highly technical process:
No Edit Functionality: Once a custom provider is connected via the UI, the only available option is a Disconnect button. There is no way to modify existing fields like the baseURL or apiKey without fully disconnecting and re-entering all settings from scratch.
No UI Model Management: Adding, removing, or adjusting configuration details (such as context and output limits) for specific models under a custom provider forces users to manually locate and edit the underlying opencode.json configuration file.
While a "configuration-first" approach is excellent for project version control, a basic graphical CRUD (Create, Read, Update, Delete) interface for connected providers and models would significantly improve the user experience, especially for users frequently swapping local models or modifying network ports.
💡 Proposed Solution
Introduce an "Edit" action alongside the existing "Disconnect" button in the Providers settings UI, and add a dynamic schema viewer/editor for registered models.
- Provider Edit Modal
Change the single Disconnect button to an actions menu or place an Edit button next to it.
Clicking Edit should open the initial connection modal with all existing fields (Provider ID, Display Name, Base URL, etc.) pre-filled with the current configuration data.
- Inline Model Manager
Under each connected custom provider in the UI, expose a list of currently registered models.
Provide an "Add Model" button that opens a simple form to define:
Model ID / Name
Context Window Limit (to prevent the Context Limit 0 / empty usage bar issue)
Output Limit
Modalities (Text, Image, etc.)
Activity
github-actions commentedon Jun 24, 2026
This issue might be a duplicate of existing issues. Please check:
/settingscommand for editingopencode.jsonvia the TUI, which partially overlaps with the provider/model management UI described here.You may want to reference or consolidate with those issues to avoid fragmentation.
mrpmorris commentedon Aug 6, 2026
I was just about to ask for an edit model
vishalkadam47 commentedon Aug 14, 2026
yes edit is required and also auto load models hard to add models when we have multi models each time when we have key changes
ydw1904 commentedon Sep 2, 2026
yea drives me crazy when i have to manually add all my models from custom provider again in the gui or edit the json when new models are released.
nawarian commentedon Sep 10, 2026
+1 here
I'd suggest us to also attempt calling
/v1/modelsendpoint in order to auto discover what the provider has to offer. This might not work for all providers, so the attempt should not crash the feature if provider returns a non-200 HTTP response.Another pain point is not being able to define model's modalities and reasoning capabilities. A user must change the
opencode.jsonmanually to do so.tttrove commentedon Oct 13, 2026
+1, same gap on my side — I moved over from Cherry Studio and expected this to just be there. A couple of things I'd add to the proposal:
Limits aren't the only part of the record people need to touch. Modalities, tool support, cost and reasoning variants are all sitting in the config and none of them are editable in a UI today. While digging into this I found a pile of related reports: #53005 (can't change limits), #54995 (image input on desktop still needs a file edit), #50713 (cost tiers), #53847 (inheriting from models.dev). Variants seem worse than just missing UI though — the auto-generated ladder is already breaking things in the wild (#53202, #54801, #54732, #53756). An editor should let people pick which levels exist and which one is default, with per-level remapping tucked under an advanced section. CC Switch does exactly that for Codex (multi-select + default level) and it's the one part of their form I actually like.
Second: make it a typed form and validate it. A typo in one model field currently takes the whole provider out of the picker with only a log line to explain it (#54973), and a variants array/object mismatch silently drops the provider too (#53744). With typed inputs those errors would show up on screen instead of looking like the provider randomly disappeared.
For the per-model editor, the fields I keep needing: limit.context / limit.input / limit.output as three number fields; capabilities.tools as a toggle; capabilities.input and output as checkboxes (text / image / audio / video / pdf); cost input, output, cache read, cache write as numbers (plus tiers if #50713 lands); variants as a level multi-select with a default; settings / headers / body can stay a raw key-value editor for the long tail.
And if the same form vocabulary is used across TUI, desktop and web, the add-provider flows would stop looking like three different products — kind of the same thing #49091 asks for on the /connect side.
opencodejr commentedon Oct 29, 2026
Thanks for the detailed write-up, @akierum! You're asking for a way to edit a connected custom provider's settings (base URL, API key, name) in the Providers settings instead of disconnecting and setting it up again. You'd also like to manage that provider's models (add/remove models, set context and output limits, modalities) in the UI rather than editing
opencode.jsonby hand. Right now the Providers settings only offer Disconnect for custom providers, so this would be new functionality. Maintainers will consider it.Related issues that each cover part of this:
/connect/settingscommand for editingopencode.json(closed)opencode.jsoncshould support inheriting data fromanomalyco/models.devvia properties when configuring provider models #53847: inheriting model data from models.dev when configuring provider modelsSergei-R9 commentedon Oct 29, 2026
+1 — hitting this in both the desktop app and the TUI.
The blocker isn't limited to custom providers. Even for a provider that's already connected, adding a model it released later means running
/connectagain and typing the API key a second time, or hand-editingopencode.json. Same for rotating a key. There's no way to remove a model or check that one actually responds, so a bad model ID only surfaces after it's selected.QwenPaw already solves this and is worth looking at directly (https://github.com/agentscope-ai/QwenPaw): Console → Settings → Models shows one card per provider, and the card is where you replace the API key, add or delete models, and test each model individually — every model on the card has its own availability check. No disconnect, no re-entering the whole provider. It's the simplest provider management I've used.
Minimum useful version here: an Edit action per connected provider (key / base URL prefilled, not re-typed), a model list with add/remove, and a per-model Test button. That alone removes the reconnect loop without a full config editor.
Related: #20598, #18224, #16292 (all closed), so this is the live thread for it.
joe-ieta commentedon Oct 30, 2026
Proposal: a V2 custom provider and model editor
Please extend this proposal to the V2 desktop/web app. Connecting a listed integration and toggling models in Manage models do not cover creating or editing an arbitrary local endpoint and its model definitions. Users still have to edit JSONC or use an external tool.
A small first version could live under Settings → Providers → Add custom provider, with Edit on existing custom providers:
Acceptance: starting from a fresh V2 client, a user can add a local model, select it, edit the endpoint and see the saved configuration after reopening the app, without editing files. Existing hand-written configurations remain usable. Advanced JSONC editing stays available.
Related: #59603 (missing custom-provider entry in V2), #51527 (V2 credential/API gap), #49091 (TUI registration flow), #49605 / #60479 (configured models hidden by the date filter). This is a product proposal for maintainer design review, separate from the narrow visibility bug fix.
Sergei-R9 commentedon Oct 30, 2026
Good scope. For points 2–3 there's a working reference: QwenPaw (https://github.com/agentscope-ai/QwenPaw). Console → Settings → Models lists providers as cards; from a card you replace the key, add/remove models, and test each model individually — every model has its own availability check. Manual entry always works even when discovery doesn't, which is why it holds up in practice.
Reusing the same card in V2 desktop/web/TUI would also stop the add-provider flows from looking like three different products.