Provider routing
Switch OpenAI, Claude, and Gemini behind one endpoint
Send one canonical messages request to supported OpenAI, Anthropic, or Gemini models while LLM Proxy owns each provider's native API contract.
Startups and product teams comparing native model families without maintaining three product integrations.
The problem
OpenAI Responses, Anthropic Messages, and Gemini Interactions use different authentication, payload, model-limit, lifecycle, and response contracts.
How LLM Proxy helps
LLM Proxy maps the same authenticated POST /v2 messages request into the selected native provider adapter and returns provider-neutral status and usage behavior to the caller.
How it works
- Configure and verify the required provider credentials behind LLM Proxy.
- Integrate the application once through POST /v2 or one of the official clients.
- Select provider=openai, provider=anthropic, or provider=gemini while keeping the messages body unchanged.
- Use the capability matrix to choose an exact supported model and any route-specific options.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Native provider adapters | The backend handles OpenAI Responses, Anthropic Messages, and Gemini Interactions differences. | Gemini messages become interaction steps; Claude system messages use Anthropic's system field. |
| One blocking caller contract | Provider resource lifecycles remain internal while the caller waits for one final response. | The product does not add OpenAI or Gemini polling code. |
| Common status mapping | Provider errors, timeouts, rate limits, and invalid inputs map to documented proxy statuses. | Callers do not parse three provider error formats. |
| Model validation | Model IDs are checked against configured provider catalogs. | A Gemini model is not accepted under Anthropic routing. |
Use-case examples
Claude writing pass
A team sends an existing /v2 transcript with provider=anthropic for editorial output.
Gemini summarization pass
The same transcript shape routes to provider=gemini for a long summary workflow.
OpenAI web search task
The caller selects an OpenAI model marked for web search and includes web_search=true.
Objections and limitations
- Provider-specific capabilities remain provider-specific; web search is currently exposed only for configured OpenAI models.
- The generated catalog is authoritative for the currently supported model routes and capabilities.
- The endpoint is shared, but the selected provider still controls upstream behavior and availability.
Repository evidence
for provider in openai anthropic gemini; do
curl -X POST "https://llm-proxy-api.mprlab.com/v2?key=$LLM_PROXY_SECRET&provider=$provider" -H "Content-Type: application/json" -d '{"messages":[{"role":"user","content":"Summarize this"}]}'
doneVerified 2026-08-08 by Tyemirov on GitHub against README.md.
FAQ
Does the request body change between OpenAI, Claude, and Gemini?
The canonical POST /v2 messages body stays the same. LLM Proxy maps it into OpenAI Responses, Anthropic Messages, or Gemini Interactions according to the selected provider and model route.
Can the application omit the model?
Yes. An omitted model uses the tenant default when provider is omitted or the selected provider's configured default when provider is explicit.
Are capabilities identical across these providers?
No. Image input, audio input, web search, reasoning, output limits, and other capabilities remain exact to the selected catalog route.
Where can a team compare the supported models?
The public landing page renders the complete current matrix from the same validated provider registry used by request routing.
What should I read next?
A closely related resource is Integrate once through one multi-provider LLM proxy, which covers multi-provider LLM proxy.
Related resources
Compare the current native-provider routes
Search the generated model matrix by provider, model, capability, contract, reasoning level, default, or output limit.
Explore supported models