Configuration
Provider default model selection for omitted models
Let omitted model fields resolve through tenant defaults or selected-provider configured defaults.
Client developers and operators who want explicit defaults without hardcoding a model in every request.
The problem
If clients omit model, each provider route needs a clear rule. Otherwise requests can accidentally inherit a stale model from the wrong provider.
How LLM Proxy helps
LLM Proxy resolves omitted model through the tenant default when provider is omitted, otherwise through the selected provider's configured default.
How it works
- Mark one text offering as the default for each provider in config.yml.
- Set tenant defaults for omitted-provider requests.
- Send provider only when a request needs a provider override.
- Omit model in bundled clients when the caller wants provider defaults.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Provider-scoped defaults | A Gemini request without model uses Gemini's configured default. | It does not inherit an OpenAI model name. |
| Client omission support | Go, CLI, and Python v2 clients omit model when no model is specified. | Provider default behavior stays server-owned. |
| Startup guardrails | A keyed provider must have a valid configured text default model. | Invalid defaults fail before traffic starts. |
Use-case examples
Provider trial
A caller sets provider=gemini and omits model to use gemini-2.5-flash from config.
Default route
A client omits provider and model to use the tenant default OpenAI route.
Managed provider settings
A user saves a provider-specific text model in Settings for generated-secret traffic.
Objections and limitations
- Omitted model behavior depends on current config and management state.
- A provider selected with an invalid model still returns 400.
- Dictation has separate provider and model defaults.
FAQ
What is the main job of provider default model selection?
LLM Proxy resolves omitted model through the tenant default when provider is omitted, otherwise through the selected provider's configured default.
Who should read this configuration resource?
Client developers and operators who want explicit defaults without hardcoding a model in every request.
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 LLM model catalog configuration in config.yml, which covers LLM model catalog configuration.
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