-
Notifications
You must be signed in to change notification settings - Fork 81
Description
Feature Type
Core library enhancement
Provider (if applicable)
No response
Description
current implementation of ReqLLM.model/1 imposes strict validation against the local LLMDB catalog. While this ensures type safety and capability checking for known models, it creates significant friction in several common real-world scenarios.
The Problem If a user attempts to use a valid model spec string (e.g., provider:new-model) that is not yet present in the local llm_db snapshot, the library raises a validation error and blocks the request. This effectively prevents users from using any model that hasn’t been explicitly indexed by the library maintainers.
Key Use Cases Affected
New Model Releases: LLM providers release new models frequently. There is often a lag between a model’s release and the corresponding update to req_llm/llm_db. Users cannot use the new model immediately without waiting for a library update or manually monkey-patching.
API Aggregators: Services like OpenRouter, Zenmux, or others often support a vast array of models, including those from smaller providers or fine-tunes that may never be in the core catalog.
Reverse Proxies / Custom APIs: Users running self-hosted proxies or standardizing via OpenAI-compatible endpoints often map models to custom names (e.g., my-internal-mix) which will fail current validation.
Example Usage
No response
Can you contribute this?
Yes, I can submit a PR