Feature Area
Integration with external tools
Is your feature request related to a an existing bug? Please link it here.
NA
Describe the solution you'd like
Add Requesty as a supported provider in the OpenAI-compatible provider set, next to OpenRouter. Requesty is an OpenAI-compatible LLM router (https://router.requesty.ai/v1) that uses the same provider/model naming convention as OpenRouter, so a model string like requesty/openai/gpt-4o-mini should route through the existing openai_compatible completion path with REQUESTY_API_KEY for auth and an optional REQUESTY_BASE_URL override (for the EU endpoint https://router.eu.requesty.ai/v1).
Concretely that means a ProviderConfig entry for requesty in llms/providers/openai_compatible/completion.py, the requesty prefix registered in llm.py (supported providers, prefix map, pattern-match branch, openai_compatible set), tests mirroring the OpenRouter cases, and a short docs section.
Describe alternatives you've considered
Today users can already reach Requesty by pointing LLM(model="openai/...", base_url="https://router.requesty.ai/v1", api_key=...) at the router by hand. That works but loses the provider/model convenience, needs the base URL repeated in every config, and is not discoverable from the docs. A first-class prefix matches how OpenRouter, DeepSeek and Cerebras are already handled.
Additional context
There is an implementation ready in #6273 (tests pass, ruff clean, live call against the router verified). The PR was auto-closed because first-time contributors need an associated issue, so this is that issue.
Disclosure: I work at Requesty. Happy to adjust anything to match project conventions.
Willingness to Contribute
Yes, I'd be happy to submit a pull request
Feature Area
Integration with external tools
Is your feature request related to a an existing bug? Please link it here.
NA
Describe the solution you'd like
Add Requesty as a supported provider in the OpenAI-compatible provider set, next to OpenRouter. Requesty is an OpenAI-compatible LLM router (
https://router.requesty.ai/v1) that uses the sameprovider/modelnaming convention as OpenRouter, so a model string likerequesty/openai/gpt-4o-minishould route through the existingopenai_compatiblecompletion path withREQUESTY_API_KEYfor auth and an optionalREQUESTY_BASE_URLoverride (for the EU endpointhttps://router.eu.requesty.ai/v1).Concretely that means a
ProviderConfigentry forrequestyinllms/providers/openai_compatible/completion.py, therequestyprefix registered inllm.py(supported providers, prefix map, pattern-match branch, openai_compatible set), tests mirroring the OpenRouter cases, and a short docs section.Describe alternatives you've considered
Today users can already reach Requesty by pointing
LLM(model="openai/...", base_url="https://router.requesty.ai/v1", api_key=...)at the router by hand. That works but loses theprovider/modelconvenience, needs the base URL repeated in every config, and is not discoverable from the docs. A first-class prefix matches how OpenRouter, DeepSeek and Cerebras are already handled.Additional context
There is an implementation ready in #6273 (tests pass, ruff clean, live call against the router verified). The PR was auto-closed because first-time contributors need an associated issue, so this is that issue.
Disclosure: I work at Requesty. Happy to adjust anything to match project conventions.
Willingness to Contribute
Yes, I'd be happy to submit a pull request