Overview
Helicone AI Gateway provides automatic fallback capabilities to ensure your AI applications remain reliable even when individual providers fail. When a request fails, the gateway automatically tries alternative providers in the order you specify.How Fallbacks Work
The gateway processes fallbacks in a predictable order:1
Primary Attempt
The gateway tries the first model/provider in your list.
2
Failure Detection
If the request fails (rate limit, timeout, service error, etc.), the gateway moves to the next option.
3
Automatic Retry
The gateway automatically retries with the next model/provider in your list.
4
Success or Exhaustion
The process continues until a request succeeds or all options are exhausted.
Fallbacks work across both BYOK (Bring Your Own Key) and PTB (Pass-Through Billing) authentication methods.
Basic Fallback Configuration
Same Model, Different Providers
Route the same model through different providers:- OpenAI (primary)
- Azure OpenAI (if OpenAI fails)
- DeepInfra (if Azure fails)
Different Models
Fallback to different models:- GPT-4o (best available provider)
- GPT-4o-mini (cheaper alternative)
- Claude Sonnet 4 (different model family)
Cross-Provider Fallback
Fallback across different cloud providers:- AWS Bedrock (primary)
- Anthropic direct (if Bedrock fails)
- Google Vertex AI (if Anthropic fails)
Common Fallback Patterns
- Cost Optimization
- Regional Resilience
- Speed Optimization
- BYOK + PTB
Try cheaper providers first, fallback to premium:Pattern:
- DeepInfra (lowest cost)
- OpenAI standard (if DeepInfra unavailable)
- GPT-4o (best quality, highest cost)
Failure Scenarios
The gateway automatically retries on these failure types:Rate Limiting (429)
Rate Limiting (429)
Provider rate limit exceeded
Exception: Helicone-generated 429s (escrow failure, rate limits) bail immediately without trying fallbacks.
Authentication Errors (401, 403)
Authentication Errors (401, 403)
Invalid or expired provider keys
Service Errors (500, 502, 503)
Service Errors (500, 502, 503)
Provider service unavailable
Timeout Errors
Timeout Errors
Request timeout
Disallowed Models
Disallowed Models
Model not available for PTB
Advanced Fallback Strategies
Multi-Model Fallback
Combine multiple models and providers:Conditional Fallbacks
Choose fallback strategy based on context:Provider Exclusions with Fallbacks
Exclude specific providers while maintaining fallbacks:Monitoring Fallbacks
Track fallback behavior in the Helicone dashboard:1
View Request Details
Open any request in Requests
2
Check Attempts
See all provider attempts and which one succeeded
3
Analyze Patterns
- Which providers fail most often?
- How many fallback attempts typically occur?
- What’s the success rate by provider?
Error Responses
When all fallback attempts fail, the gateway returns a consolidated error:Fallback Best Practices
Start with Native Providers
Start with Native Providers
List the native provider first for best compatibility:
Balance Cost and Reliability
Balance Cost and Reliability
Mix low-cost and reliable providers:
Keep Fallback Chains Short
Keep Fallback Chains Short
2-4 fallbacks is usually sufficient:
Monitor Fallback Frequency
Monitor Fallback Frequency
If fallbacks trigger frequently:
- Check provider status
- Verify BYOK keys
- Consider changing primary provider
- Review rate limits
Test Your Fallback Strategy
Test Your Fallback Strategy
Test fallbacks by:
- Using invalid BYOK keys temporarily
- Requesting rate-limited models
- Monitoring which providers succeed
Real-World Examples
Production-Grade Fallback
Cost-Optimized with Fallback
Regional Resilience
Streaming with Fallbacks
Fallbacks work seamlessly with streaming:Next Steps
Routing
Learn more about provider routing
Getting Started
Set up the AI Gateway
Monitor Requests
Track fallback behavior
Browse Models
Explore available models
