LLM Proxy

Configuration

LLM model catalog configuration in config.yml

Keep exact model identity and provider offerings in normalized runtime config.

Operators maintaining provider model availability without changing application code.

The problem

Model lists change faster than client release cycles. Hardcoded model IDs in callers make provider updates brittle.

How LLM Proxy helps

LLM Proxy keeps publishers, families, exact models, providers, and provider offerings in normalized runtime configuration.

How it works

  1. Declare each publisher, family, exact model, provider, and provider offering in config.yml.
  2. Declare operation defaults on provider offerings.
  3. Add request profiles, web_search flags, and limits only to supported offerings.
  4. Restart the service after changing runtime config.

Feature-to-benefit table

Feature Why it matters here Example
Normalized identity Exact models remain independent from provider-native identifiers. One exact model can have multiple provider offerings.
Startup validation Duplicate routes, dangling references, and missing defaults fail startup. Bad catalogs are caught before serving traffic.
Offering metadata Output token limits and OpenAI request profiles are explicit. Known ceilings can be rejected before upstream calls.

Use-case examples

Gemini catalog update

An operator adds a Gemini exact model and provider offering to config.yml.

Claude default change

A tenant selects a configured Claude default without changing client calls.

OpenAI web-search gate

Only OpenAI model entries marked with web_search expose that request option.

Objections and limitations

  • Adding a provider that has no adapter still requires code work.
  • Config changes require restart to take effect.
  • Unknown YAML keys fail startup under the current strict config contract.

FAQ

What is the main job of LLM model catalog configuration?

LLM Proxy keeps publishers, families, exact models, providers, and provider offerings in normalized runtime configuration.

Who should read this configuration resource?

Operators maintaining provider model availability without changing application code.

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 Provider default model selection for omitted models, which covers provider default model selection.

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