Auto-discover models from OpenAI-compatible provider endpoints

Description

For OpenAI-compatible local providers (LM Studio, Ollama, llama.cpp, etc.), users currently need to manually list all available models in their opencode.json configuration. This is tedious and error-prone, especially for local providers where models change frequently as they are loaded/unloaded.

Most OpenAI-compatible providers expose a standard /v1/models endpoint that lists all available models. OpenCode should automatically query this endpoint and discover available models, eliminating the need for manual configuration.

Proposed Solution

When a provider uses @ai-sdk/openai-compatible, OpenCode should:

Make a GET request to {baseURL}/models (e.g., http://localhost:1234/v1/models)
Parse the response to extract available models
Automatically populate the model list, merging with any manually configured models
Optionally refresh this list periodically or on-demand

Benefits

Better UX: No manual model configuration needed
Dynamic updates: Automatically reflects models as they're loaded/unloaded in local servers
Fewer errors: Eliminates misconfiguration issues
Consistency: Works the same way across all OpenAI-compatible providers

Current Workaround

Users can:

Manually query http://localhost:1234/v1/models to see available models
Manually add each model to opencode.json
Use the community plugin opencode-lmstudio for LM Studio

Example: Current Manual Configuration

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      },
      "models": {
        "google/gemma-3n-e4b": {
          "name": "Gemma 3n-e4b (local)"
        },
        "qwen/qwen3-coder-30b": {
          "name": "Qwen 3 Coder 30B"
        }
      }
    }
  }
}

Example: Proposed Auto-Discovery

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      }
      // models automatically discovered!
    }
  }
}

OpenCode Version

1.0.58+

Additional Context

The opencode-lmstudio plugin already implements this functionality successfully for LM Studio. Consider integrating similar logic into core OpenCode for all @ai-sdk/openai-compatible providers.

This issue might be a duplicate of or closely related to existing issues. Please check:

OpenCode displays models which aren't configured & don't exist in LM Studio #4232: OpenCode displays models which aren't configured & don't exist in LM Studio - related issue with LM Studio model configuration
Add OpenAI-compatible /v1/models endpoint to OpenCode Zen for automatic model discovery #2901: Add OpenAI-compatible /v1/models endpoint to OpenCode Zen for automatic model discovery - complementary feature for the Zen endpoint

Feel free to ignore if none of these address your specific case.

I'm using Ollama Cloud, it seems that OpenCode pulled the available models initially... but it isn't aware of changes. I've used opencode models --refresh... but that doesn't pick up the new ones. (1.0.209)

I have a custom AI provider with 100+ models and new models are added daily. Manually configuring each model in opencode.json is completely unsustainable - I would need to update the config every single day just to keep up with new models.

This issue describes exactly what I need: automatic model discovery from the provider's /v1/models endpoint. The proposed solution of querying {baseURL}/models and automatically populating the model list would solve my problem completely.

I see there are active PRs working on this:

add models endpoint #13234 - adds models endpoint (models-endpoint branch)
opencode: added logic to probe loaded models from lmstudio, ollama an… #11951 - probes loaded models from LM Studio, Ollama, etc. (models-endpoint branch)
Adding the auto-detection of ollama local with a variable for baseURL #3726 - auto-detection of Ollama with baseURL variable

These implementations on the models-endpoint branch appear to be the solution this issue requests. Once merged, users like me with large, dynamic model catalogs won't need manual configuration anymore.
Related issues with the same root cause:

Local Ollama models not included in model listing, breaking plugin model discovery #12243 - Local Ollama models not included in model listing
LM Studio Failure to refresh models #2047 - LM Studio Failure to refresh models
The cache of the Provider‘s Models cannot be updatable #7714 - The cache of the Provider's Models cannot be updatable
No endpoints found error from Openrouter -> Should be able to re-fetch/update model list #10594 - Should be able to re-fetch/update model list

@manascb1344

Similar to @manascb1344 I both personally and at work run AI gateways (Bifrost, llama-swap) that expose many different models to myself and other users.

Having to manually edit opencode.jsonc and add in model information for models that are already listed with their required details via the /models endpoint is incredibly painful.

It would be great if OpenCode could list the available models from an endpoint rather than relying on hard coding model names manually.

To get by in the mean time, I made a hacky little TUI script to make it easier to add discovered models from your endpoint to OpenCode https://github.com/sammcj/opencode-model-tool

Add local server provider with automatic model discovery

It's so hard to believe this is not in opencode. I thought I was being stupid and don't know how to use the software, modifying jsons all day to try new local models. (my config is a mess now). Please bring it asap.

Add local server provider with automatic model discovery

I've been waiting for this for a while. Nothing happened, then I created a plugin for that, https://github.com/yuseferi/opencode-litellm.
temporary solution until it goes to opencode

https://gitea.com/mcepl/ollama_dynamic_models.git another approach

+1 on this - over the at OGX project we have Open AI-compatible endpoints for a unified server which itself routes to various of our own providers - this would make it much easier for OpenCode to work even better with OGX (right now it works as a custom provider but models must be configured manually)

+1 is just a pain to manually addiing and removing models, when we have all the tools to just make it detect and update the list automatically

+1
This is a big pain with OpenCode.

Also, OpenCode currently lists ghost models we never configured, from LM Studio, that they get from models.dev

See #2047 (comment) and #25351

That should be avoided too, to avoid polluting our models list.

see this

https://github.com/MohammadMD1383/opencode-dynamic-config

Also include reload and edit options

It's absolutely mindblowing that this has never been implemented. Developers can be soooo shortsighted....

OpenCode v1 has already entered the maintenance phase, so a change like this clearly won't be included in it.
As for when OpenCode v2 will be released—perhaps in a few months?

This use case is already supported by the community plugin:
https://github.com/yuhp/opencode-models-discovery

It supports automatic model discovery for any configured @ai-sdk/openai-compatible provider and injects the discovered models into provider.<name>.models during the config hook.

Example:

{
  "plugin": ["opencode-models-discovery@latest"],
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1",
        "modelsDiscovery": {
          "enabled": true
        }
      }
    }
  }
}

The plugin supports custom model endpoints, timeouts, model filters, provider-specific metadata enrichment, OpenCode /connect credentials, and optional persisted caching. Discovery failures leave explicitly configured models intact.

The current limitation is that discovery happens during config initialization, rather than through a continuously running background refresh. Native support in OpenCode would still be useful, but this plugin can serve as a working solution for the startup-time auto-discovery use case today.

This use case is already supported by the community plugin: https://github.com/yuhp/opencode-models-discovery

I discovered it already shortly after that post, thanks for making it, very useful. But it's still wild that it wasn't a part of the base project since v1.0.0.

Glad to hear the plugin has been useful, and thank you for the feedback. I agree that model discovery from standard OpenAI-compatible endpoints is a natural core capability, especially for local and self-hosted providers.

Until native support is available, the plugin aims to provide a practical workaround while also covering provider-specific endpoints, filtering, metadata enrichment, credentials, and caching.

feat(core): add opt-in model auto-discovery for OpenAI-compatible pro…

Strong +1 from a Windows Desktop user maintaining two custom OpenAI-compatible providers in opencode.json (10+ models each, hand-written provider.*.models entries).

Our specific pain (matches this issue's ask): every time the provider ships a new model we have to hand-edit the config again — type the model id, display name, sometimes capabilities. Stale/wrong entries accumulate (we've had to prune model entries that no longer exist upstream), and there is no way to "refresh" the list.

Concrete request, in priority order:

When a custom OpenAI-compatible provider is added (Desktop UI), call the endpoint's model-list API (GET /models and friends) and auto-populate the model entries — no manual typing.
A one-click "refresh model list" on the provider in the /models dialog, so new upstream models can be added without hand-editing JSON.
(Nice-to-have) warn/skip entries that the upstream no longer reports, instead of silently 404ing later.

Happy to be a test case for a Desktop "add custom provider → auto-detect models" flow — our config is the worst-case (two providers, manual entries, frequent upstream model churn). Filed as our feature request here rather than a duplicate issue; please link/close any of our duplicates against this one.

fwiw lmstudio auto discovery works in opencode 2 but you need to hardcode the api key if using authentication

#51570 (comment)

I think what's missing from this implementation is that custom providers don't want "lmstudio" or "ollama" or "vllm" or whatever in the config as the "provider" key for the models.

On the server side it's easy enough to get an llm to proxy the requests to any of these endpoints, but a custom provider (especially if they are selling inference) doesn't want to list something they aren't using, or even are (because security through obscurity is still helpful).

Can the provider be "custom-provider" and they can list the "kind" in a "source-type" or "api-compatibility" key? If one is running 6 models with SGLang and VLLM across several servers, the current format seems more than unprofessional to try to provide to a client.

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Issue persist, I'm on 2.0.26. Forced to use external plugins like one from yuhp. While you added ollama and other runtimes discovery, people who use anything else can't really list. Something like LocalAI that is openai-compatible cannot list it automatically and users have to result to manually specifying models. Workaround is to spoof it for one of 3 supported runtimes and pray it works which it doesn't. For example with localai only lmstudio spoof lists at least some models but not all.

I quite don't undestand why does this happen whether its because its behind apiKey or not because json looks to me exactly like ollama one just missing some fields. Here's print from v1/models

{"object":"list","data":[{"id":"dreamshaper","object":"model"},{"id":"face-detect-buffalo-s","object":"model"},{"id":"GLM-4.7-Flash-GGUF","object":"model"},{"id":"ornith-1.5-9b-q4","object":"model"},{"id":"qwen3-embedding-8b","object":"model"},{"id":"qwen3.8-9b-q8","object":"model"},{"id":"qwopus3.6-35b-a3b-coder-mtp","object":"model"},{"id":"acestep-cpp-turbo-4b","object":"model"},{"id":"localvqe-v1.3-4.8m","object":"model"},{"id":"Z-Image-Turbo","object":"model"},{"id":"embeddinggemma-300m","object":"model"},{"id":"flux.2-klein-9b","object":"model"},{"id":"nanbeige4.1-3b-q4","object":"model"},{"id":"ornith-1.5-9b-obliterated-q4","object":"model"},{"id":"parable-qwen3-8b-claude-fable-5","object":"model"},{"id":"qwen3-tts-cpp","object":"model"},{"id":"qwopus3.8-27b-flash","object":"model"},{"id":"agents-a1-4b","object":"model"},{"id":"privacy-filter-nemotron","object":"model"},{"id":"qwen3.6-14b-a3b-fablevibes","object":"model"},{"id":"qwen3.8-27b-obliterated-q4","object":"model"},{"id":"supertonic-3","object":"model"},{"id":"whisper-large","object":"model"},{"id":"flux.2-klein-4b","object":"model"},{"id":"glm-ocr","object":"model"},{"id":"qwen3-embedding-0.6b","object":"model"},{"id":"qwen3.6-35b-a3b-uncensored-heretic","object":"model"},{"id":"qwen3.8-27b-dflash2","object":"model"},{"id":"thomson-1.0-small-q4","object":"model"},{"id":"face-detect-buffalo-l","object":"model"},{"id":"qwen3-tts-llamacpp","object":"model"},{"id":"deepseek-ocr","object":"model"},{"id":"gemma-4-e4b-it","object":"model"},{"id":"instella-moe-16b-a3b-think","object":"model"},{"id":"lfm2.5-audio-1.5b-realtime","object":"model"},{"id":"stable-diffusion-x4-upscaler","object":"model"},{"id":"trellis2-4b","object":"model"},{"id":"wan-2.1-t2v-1.3b-ggml","object":"model"},{"id":"whisper-base-en","object":"model"},{"id":"LittleBoy","object":"model"},{"id":"qwen3.8-27b-q4-mtp","object":"model"},{"id":"security-slm-gemma-4-e2b-it-q4","object":"model"},{"id":"vibevoice-cpp","object":"model"}]}

Yes, please reopen. This still apply to opencode v2.0.31

Navigation Menu

Repository navigation

Auto-discover models from OpenAI-compatible provider endpoints #6231

Description

Proposed Solution

Benefits

Current Workaround

Example: Current Manual Configuration

Example: Proposed Auto-Discovery

Related

OpenCode Version

Additional Context

45 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Auto-discover models from OpenAI-compatible provider endpoints #6231

Description

Description

Proposed Solution

Benefits

Current Workaround

Example: Current Manual Configuration

Example: Proposed Auto-Discovery

Related

OpenCode Version

Additional Context

Activity

github-actions commented on Dec 27, 2025

mdlmarkham commented on Dec 30, 2025

manascb1344 commented on Feb 15, 2026

sammcj commented on Feb 27, 2026

sammcj commented on Feb 28, 2026

sgmihai commented on Mar 21, 2026

yuseferi commented on Apr 27, 2026

e-minguez commented on Apr 29, 2026

nathan-weinberg commented on Apr 30, 2026

gggiiia commented on May 3, 2026

hyuri commented on Jun 11, 2026

MohammadMD1383 commented on Jun 17, 2026

45 remaining items

vishalkadam47 commented on Sep 4, 2026

brrreaker commented on Sep 9, 2026

linghengqian commented on Sep 9, 2026

yuhp commented on Sep 11, 2026

brrreaker commented on Sep 11, 2026

yuhp commented on Sep 11, 2026

liudongyan13701205717-source commented on Sep 25, 2026

joepetrakovich commented on Sep 27, 2026

jeremiahlangner commented on Oct 2, 2026

thdxr commented on Oct 11, 2026

darukutsu commented on Oct 11, 2026

ohmer1 commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions