Skip to main content
December 2025 Update: Battle-tested patterns for handling LLM failures, implementing retries, and building resilient AI applications.

LLM Failure Modes

Think of an LLM API like a restaurant kitchen during a rush. Sometimes orders get backed up (rate limiting), sometimes the chef takes too long (timeouts), sometimes the dish comes out wrong (invalid responses), and occasionally the entire kitchen shuts down (service outages). Just as a great restaurant has contingency plans for each scenario, your application needs a strategy for every failure mode. Understanding how LLMs fail is crucial for building resilient systems:

Comprehensive Error Handling

Custom Exception Hierarchy


Retry Strategies

Exponential Backoff with Jitter


Circuit Breaker Pattern

Think of a circuit breaker like the fuse box in your house. When too much current flows through a circuit, the fuse trips to prevent a fire. Similarly, when an LLM provider starts failing repeatedly, you want to “trip” the breaker — stop sending requests that will inevitably fail, give the provider time to recover, and then cautiously test whether it is back. Without this, a single degraded provider can drag down your entire application as requests pile up waiting for timeouts. Prevent cascading failures with circuit breakers:

Provider Failover

Imagine you are booking a flight. Your first choice is a direct flight, but if that is sold out you check a connection through another hub, and if that fails you look at a completely different airline. Provider failover works the same way — you rank your LLM providers by preference (cost, quality, latency) and automatically cascade through them when one is unavailable. The key insight: a slightly worse response from a backup provider is almost always better than returning an error to the user.

Response Validation

LLMs are probabilistic — even when you ask for JSON, you might get markdown, a preamble, or a partially valid structure. Response validation is the seatbelt you never skip. The pattern here is “validate, then re-prompt”: if the response does not match your schema, feed the validation error back to the LLM and ask it to fix its output. Most models self-correct within one or two retries.

Timeout Management

LLM calls are unpredictable in latency. A simple summarization might return in 2 seconds one day and 45 seconds the next. Without explicit timeouts, a single slow request can hold an async worker hostage, and if you have a fixed worker pool, a few slow calls can starve every other user. Think of timeouts as a contract with your users: “I promise an answer within N seconds, or I’ll tell you I couldn’t get one.”

Graceful Degradation

Graceful degradation is the difference between Netflix showing you a slightly stale recommendation versus a blank screen. When your primary LLM path fails, you want to cascade through options: try the cache for a recent answer, try a simpler prompt that is more likely to succeed, and as a last resort, return a pre-written fallback. The user should always get something useful. The tuple (response, source) pattern below makes it easy to track how often you are degrading, which is a key operational health metric.

Unified Error Handler

Your API consumers should never see raw OpenAI or Anthropic error messages. This handler translates internal LLM errors into clean, predictable HTTP responses with appropriate status codes. The mapping is deliberate: a rate limit from the provider becomes a 429 to the client so their retry logic kicks in, while a content filter violation becomes a 422 so they know to fix the input rather than retry.

Key Takeaways

Expect Failures

Design for failure from the start with proper exception handling

Implement Retries

Use exponential backoff with jitter for transient failures

Circuit Breakers

Prevent cascading failures with circuit breakers

Graceful Degradation

Always have fallback options for critical paths

What’s Next

Batch Processing

Learn to process large volumes of LLM requests efficiently