Overview
LiteLLM provides standardized exception types that mirror OpenAI’s exception structure while adding provider-specific information and retry tracking.Base Exception Hierarchy
All LiteLLM exceptions inherit from their OpenAI counterparts:Exception Types
AuthenticationError
Raised when authentication fails (status code: 401).Attributes
int
HTTP status code (401)
string
Error message with litellm prefix
string
Provider that raised the error (e.g., “openai”, “anthropic”)
string
Model that was being called
httpx.Response
The HTTP response object
int
Number of retries attempted
int
Maximum retries configured
Example
BadRequestError
Raised for invalid requests (status code: 400).Attributes
Same as AuthenticationError, plus:dict
Response body containing error details
Example
NotFoundError
Raised when the requested resource/model is not found (status code: 404).Example
RateLimitError
Raised when rate limits are exceeded (status code: 429).Attributes
Includes all base attributes, plus provider-specific rate limit headers in the response.Example
Timeout
Raised when a request times out (status code: 408 or provider-specific).Example
ContextWindowExceededError
Subclass of BadRequestError. Raised when the input exceeds the model’s context window.Example
ContentPolicyViolationError
Subclass of BadRequestError. Raised when content violates provider’s safety policies.Example
ServiceUnavailableError
Raised when the provider’s service is unavailable (status code: 503).Example
InternalServerError
Raised for server-side errors (status code: 500).Example
APIError
Generic API error for various status codes.Example
APIConnectionError
Raised when connection to the API fails.Example
Error Handling Patterns
Basic Error Handling
Retry with Exponential Backoff
Fallback to Different Model
Handle Context Window Errors
Logging All Errors
Using Router with Retries
Common Exception Scenarios
Scenario 1: API Key Issues
Scenario 2: Rate Limiting
Scenario 3: Model Overloaded
Best Practices
- Always catch specific exceptions rather than generic Exception
- Use Router for automatic retries and fallbacks in production
- Implement exponential backoff for rate limit errors
- Log errors with context including provider, model, and retry count
- Have fallback models configured for critical paths
- Respect retry-after headers from providers
- Monitor error rates to detect systemic issues