Repository navigation
[FEATURE]: Allow custom provider models to reference official model definitions from Models.dev #30519
Description
Feature hasn't been suggested before.
- I have verified this feature I am about to request hasn't been suggested before.
Describe the enhancement you want to request
TL;DR: Allow a model in a custom provider to reference/alias an official model definition from Models.dev by ID, so limit, modalities, reasoning, interleaved, cost, etc. are inherited automatically without manual duplication.
Problem
Many users run self-hosted gateways or proxies (e.g. LiteLLM, OpenRouter-style routers, or enterprise AI hubs) that re-expose models already cataloged in Models.dev under providers like zai, moonshotai, minimax, anthropic, etc. Currently, every custom provider that offers these models must manually re-specify all model metadata:
{
"provider": {
"my-gateway": {
"npm": "@ai-sdk/openai-compatible",
"options": { "baseURL": "http://my-gateway.example.com/api/v1" },
"models": {
"glm-5.1": {
"name": "GLM-5.1",
"reasoning": true,
"tool_call": true,
"temperature": true,
"attachment": false,
"interleaved": { "field": "reasoning_content" },
"modalities": { "input": ["text"], "output": ["text"] },
"limit": { "context": 200000, "output": 131072 }
},
"kimi-k2.6": {
"name": "Kimi-K2.6",
"reasoning": true,
"tool_call": true,
"temperature": true,
"attachment": true,
"modalities": { "input": ["text", "image"], "output": ["text"] },
"limit": { "context": 262144, "output": 131072 }
},
"MiniMax-M2.7": {
"name": "MiniMax-M2.7",
"reasoning": true,
"tool_call": true,
"temperature": true,
"modalities": { "input": ["text"], "output": ["text"] },
"limit": { "context": 204800, "output": 131072 }
}
}
}
}
}When the same models appear under multiple custom providers, all metadata is duplicated. This is error-prone and drifts out of sync with upstream model updates.
Suggested behavior
Add a way for a model in a custom provider to reference an official model definition. Proposed syntax options:
Option A — ref field (model-level reference)
{
"provider": {
"my-gateway": {
"npm": "@ai-sdk/openai-compatible",
"options": { "baseURL": "http://my-gateway.example.com/api/v1" },
"models": {
"glm-5.1": {
"ref": "zai/glm-5.1"
},
"kimi-k2.6": {
"ref": "moonshotai/kimi-k2.6"
},
"MiniMax-M2.7": {
"ref": "minimax/MiniMax-M2.7"
}
}
}
}
}Option B — use id to auto-resolve from global Models.dev index
If a model id matches a known model in any Models.dev provider, automatically hydrate metadata:
{
"provider": {
"my-gateway": {
"npm": "@ai-sdk/openai-compatible",
"options": { "baseURL": "http://my-gateway.example.com/api/v1" },
"models": {
"glm-5.1": {}, // auto-resolved from zai/glm-5.1 in Models.dev
"kimi-k2.6": {}, // auto-resolved from moonshotai/kimi-k2.6
"MiniMax-M2.7": {} // auto-resolved from minimax/MiniMax-M2.7
}
}
}
}In both options, explicit user config fields should take precedence over the referenced definition (deep merge with user wins).
Benefits
- DRY — no more duplicating limit, modalities, reasoning, interleaved, cost across custom providers.
- Accuracy — metadata stays in sync with Models.dev as upstream providers update specs.
- Ergonomics — adding a model to a custom gateway becomes a one-liner instead of a 10-line block.
Related
- [FEATURE]: Hydrate custom provider model metadata from /v1/models and Models.dev #25407 — Requests auto-hydration from
/v1/modelsendpoint (complementary but different: that issue is about runtime discovery, this issue is about static config referencing). - [Bug] Custom provider models fail with "maxOutputTokens must be >= 1" when limit is not defined #22253 — Custom provider models crash when
limitis not defined (this would also be mitigated by auto-hydration from Models.dev). - custom providers do not inherit provider loaders #18486 — Custom providers do not inherit provider loaders (related inheritance gap).
Activity
github-actions commentedon Jun 3, 2026
This issue might be a duplicate of an existing issue. Please check:
refconfig vs. runtime/v1/modelsdiscovery). Please review whether your request could be addressed under that issue or if the distinction warrants a separate track.gzb1128 commentedon Jun 3, 2026
Thanks for the triage. To clarify why this is distinct from #25407:
#25407 asks for runtime discovery — call the custom gateway's
/v1/modelsendpoint at startup and hydrate metadata from whatever that endpoint returns. The gateway itself is the source of truth.This issue asks for static config referencing — the user explicitly declares which models exist under their custom provider, and each model entry references a known model definition from Models.dev by ID. The Models.dev catalog is the source of truth.
The key difference:
/v1/models/v1/models?In practice, many self-hosted gateways are internal proxies that forward to upstream providers. They don't always expose a standards-compliant
/v1/modelsendpoint, and the models they serve are often exact re-exposures of models already in Models.dev. A staticrefmechanism is both simpler and more reliable for this use case.Both features are complementary and could coexist. But they solve different problems and should be tracked separately.
github-actions commentedon Aug 3, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
2st6z2tbvt commentedon Aug 8, 2026
I'm hitting this exact pain point with Cloudflare AI Gateway. The built-in cloudflare-ai-gateway provider in OpenCode only auto-discovers Workers AI models — third-party models routed through the gateway (DeepSeek, Google Gemini, xAI Grok, etc.) have no models.dev metadata available under that provider.
This means I have to manually copy limit.context, limit.output, modalities, capabilities (tool_call, reasoning, etc.) for every model from their original models.dev entries — exactly the duplication problem described here. A ref field like:
"cloudflare-ai-gateway": {
"models": {
"deepseek/deepseek-v4-flash": { "ref": "deepseek/deepseek-v4-flash" },
"google/gemini-3.6-flash": { "ref": "google/gemini-3.6-flash" }
}
}
would eliminate all of that. The data already exists in models.dev, just under the original provider entries.
This issue appears to have been auto-closed by the bot cleanup. Could you please reopen it? This pattern applies to any gateway/proxy setup (OpenRouter, LiteLLM, CF AI Gateway, self-hosted proxies), not just my case.