Reliability
LLM Proxy status code map for callers
Handle missing keys, bad inputs, rate limits, disabled providers, timeouts, and upstream failures consistently.
Developers who need predictable error handling around LLM and dictation calls.
The problem
Provider errors can be inconsistent. Callers need to know whether a request failed because of authentication, validation, capacity, provider rate limits, or upstream failure.
How LLM Proxy helps
LLM Proxy maps public errors to documented HTTP status codes across text and dictation routes.
How it works
- Treat 400 as invalid request parameters or unsupported provider/model/capability.
- Treat 403 as missing or invalid tenant secret.
- Treat 413 as prompt or audio payload too large.
- Handle 429, 503, 504, and 502 according to rate-limit, disabled-provider, timeout, and upstream-failure meanings.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Client validation errors | Bad provider/model choices and ambiguous bodies return 400. | Callers can fix request shape. |
| Authentication boundary | Missing or invalid key returns 403. | The proxy does not reveal tenant internals. |
| Provider/capacity signals | 429, 503, 504, and 502 communicate distinct runtime conditions. | Retry behavior can be more precise. |
Use-case examples
Disabled provider
A selected non-default provider without an API key returns 503 provider not configured.
Long provider work
A request exceeding its accepted proxy work budget returns the canonical request_timeout 504 envelope.
Provider outage
A non-rate-limit upstream provider failure maps to bad gateway behavior.
Objections and limitations
- The status map does not guarantee provider recovery.
- Callers should still log request context without secrets.
- Provider-specific error details may be normalized or wrapped by the proxy.
FAQ
What is the main job of LLM proxy status code map?
LLM Proxy maps public errors to documented HTTP status codes across text and dictation routes.
Who should read this reliability resource?
Developers who need predictable error handling around LLM and dictation calls.
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 OpenAI background response polling without client loops, which covers OpenAI background response polling.
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