[FEATURE]: Discover models from a built-in provider's own API when the models.dev catalog lags

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

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

• #27553 and #35855 request /v1/models discovery for custom OpenAI-compatible providers configured with a baseURL and 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.
• #40911 — same problem, NVIDIA provider.

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.