API contract
Per-request provider and model selection
Use provider and model parameters only when a request should override tenant or provider defaults.
Application developers who want simple defaults plus controlled overrides for special tasks.
The problem
A single application may need mostly default routing but occasional provider or model changes for a specific workflow.
How LLM Proxy helps
LLM Proxy accepts provider and model on public endpoints while preserving omitted-provider and omitted-model default behavior.
How it works
- Omit provider and model for the authenticated tenant default route.
- Set provider when a request needs a different provider.
- Set model only when a request needs a specific configured model.
- Let query/body model conflict checks protect ambiguous JSON POST requests.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Provider query parameter | GET, POST, /v2, and /dictate accept provider where supported. | A caller can override route per request. |
| Model request field | Model can be set in query or JSON body according to endpoint rules. | Unknown models return 400. |
| Default resolution | Omitted values use tenant defaults or selected-provider defaults. | Simple clients stay simple. |
Use-case examples
Default call
An app sends only prompt and key to use tenant defaults.
Gemini experiment
One endpoint call includes provider=gemini and omits model.
Specific OpenAI model
A request includes model=gpt-5 when the task needs that configured model.
Objections and limitations
- Model identifiers are provider-scoped.
- POST /v2 rejects prompt and body system_prompt even when provider/model are valid.
- Unsupported provider capabilities fail before provider calls.
FAQ
What is the main job of per-request provider model selection?
LLM Proxy accepts provider and model on public endpoints while preserving omitted-provider and omitted-model default behavior.
Who should read this api contract resource?
Application developers who want simple defaults plus controlled overrides for special tasks.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Canonical /v2 chat messages API for LLM calls, which covers v2 chat messages API.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference