Skip to main content

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

  1. Always catch specific exceptions rather than generic Exception
  2. Use Router for automatic retries and fallbacks in production
  3. Implement exponential backoff for rate limit errors
  4. Log errors with context including provider, model, and retry count
  5. Have fallback models configured for critical paths
  6. Respect retry-after headers from providers
  7. Monitor error rates to detect systemic issues