An AI outage should degrade a feature, not take down your application. Recent Claude status incidents, including elevated errors affecting Fable and Mythos models, are a useful reminder that reliability must be designed at the application layer.
A fallback wrapper should do four things: set a short timeout, retry only temporary failures, record the failure, and choose a second provider or local response path. Do not blindly retry every exception. Authentication errors, invalid requests, and content-policy responses are not fixed by waiting.
A minimal architecture has an AIClient interface with a generate() method. The primary implementation calls Claude. The fallback implementation calls another approved model or returns a deterministic template for low-risk tasks. Your business logic talks to the interface, so provider changes do not spread through the codebase.
Add a circuit breaker once the basic version works. After several consecutive failures, stop sending requests to the unhealthy provider for a short cooling period. This prevents a traffic storm and makes recovery faster. Log request IDs, latency, error classes, and fallback usage – but never store sensitive prompts unless your retention policy allows it.
Test the fallback before an outage. Simulate timeouts, malformed responses, rate limits, and partial provider failures. A fallback that exists only on paper is not resilience; it is an untested assumption.