Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
Built-in providers get their model catalog from models.dev. When a vendor ships new models, the catalog lags — often for weeks — and those models are unreachable from opencode even though the user's existing API key can already call them.
Abacus is a persistent case. Measured today against https://routellm.abacus.ai/v1/models:
models.dev lists 95 Abacus models- the Abacus API returns 153 models, 74 of them
model_type: text_generation
- 12 of those 74 are missing from
models.dev, among them claude-opus-5, moonshotai/Kimi-K3, moonshotai/Kimi-K2.7-Code, gemini-3.6-flash, deepseek-ai/DeepSeek-V4-Flash-0731 and thinkingmachines/Inkling
The important part is that this is not a one-time gap that a single models.dev PR closes for good. Abacus adds models continuously, so the catalog drifts again within weeks. Filing a catalog PR every time a vendor ships a model doesn't scale for the contributor or for the maintainers.
The only way I've found to keep working is to maintain my own copy of the model database: a script runs on shell startup, fetches /v1/models, merges the missing entries into a local catalog, and I point OPENCODE_MODELS_PATH at it. It works, but every Abacus user has to reinvent the same workaround.
It isn't only Abacus — #40911 reports the same shape for NVIDIA: moonshotai/kimi-k2.6 is served by NVIDIA's API but absent from the NVIDIA provider.
Proposed enhancement
Let a built-in provider optionally discover models from its own API and merge them into the catalog, with models.dev always winning for models it already describes, since its metadata is richer.
Most of the plumbing already exists. A custom loader can return discoverModels, and provider.ts registers it into discoveryLoaders for any provider:
https://github.com/anomalyco/opencode/blob/fe82a1b6c/packages/opencode/src/provider/provider.ts#L1675
But the invocation is hardcoded to one provider:
https://github.com/anomalyco/opencode/blob/fe82a1b6c/packages/opencode/src/provider/provider.ts#L1598
so a loader registered by any other provider is never called. Turning that into a loop over discoveryLoaders makes the existing mechanism usable by any provider, with no behavior change for gitlab.
Related
I have a working implementation for Abacus, rebased on current dev and typechecking clean, in #34563. That PR was swept by the automated cleanup and never referenced an issue — this would be the issue it should have linked.
Feature hasn't been suggested before.
Describe the enhancement you want to request
Problem
Built-in providers get their model catalog from
models.dev. When a vendor ships new models, the catalog lags — often for weeks — and those models are unreachable from opencode even though the user's existing API key can already call them.Abacus is a persistent case. Measured today against
https://routellm.abacus.ai/v1/models:models.devlists 95 Abacus modelsmodel_type: text_generationmodels.dev, among themclaude-opus-5,moonshotai/Kimi-K3,moonshotai/Kimi-K2.7-Code,gemini-3.6-flash,deepseek-ai/DeepSeek-V4-Flash-0731andthinkingmachines/InklingThe important part is that this is not a one-time gap that a single
models.devPR closes for good. Abacus adds models continuously, so the catalog drifts again within weeks. Filing a catalog PR every time a vendor ships a model doesn't scale for the contributor or for the maintainers.The only way I've found to keep working is to maintain my own copy of the model database: a script runs on shell startup, fetches
/v1/models, merges the missing entries into a local catalog, and I pointOPENCODE_MODELS_PATHat it. It works, but every Abacus user has to reinvent the same workaround.It isn't only Abacus — #40911 reports the same shape for NVIDIA:
moonshotai/kimi-k2.6is served by NVIDIA's API but absent from the NVIDIA provider.Proposed enhancement
Let a built-in provider optionally discover models from its own API and merge them into the catalog, with
models.devalways winning for models it already describes, since its metadata is richer.Most of the plumbing already exists. A custom loader can return
discoverModels, andprovider.tsregisters it intodiscoveryLoadersfor any provider:https://github.com/anomalyco/opencode/blob/fe82a1b6c/packages/opencode/src/provider/provider.ts#L1675
But the invocation is hardcoded to one provider:
https://github.com/anomalyco/opencode/blob/fe82a1b6c/packages/opencode/src/provider/provider.ts#L1598
so a loader registered by any other provider is never called. Turning that into a loop over
discoveryLoadersmakes the existing mechanism usable by any provider, with no behavior change for gitlab.Related
/v1/modelsdiscovery for custom OpenAI-compatible providers configured with abaseURLand no static model list (Ollama, LM Studio, llama-swap). This request is the adjacent case: a built-in provider that does have a catalog, but an incomplete and drifting one.I have a working implementation for Abacus, rebased on current
devand typechecking clean, in #34563. That PR was swept by the automated cleanup and never referenced an issue — this would be the issue it should have linked.