- Surviving transient provider errors without surfacing failures to end users.
- Automatic failover to a backup provider when the primary is degraded or rate-limited.
- Absorbing short rate-limit bursts without manual intervention or custom retry logic.
- Meeting availability SLAs on production features without adding retry code to every service.
Retries
Retry failed requests automatically with exponential backoff. Configure which HTTP error codes trigger retries and how many attempts to make.
Fallbacks
Route to a different model when the primary fails. Define a fallback chain across providers for high availability.
Retries
Automatically retry failed requests with exponential backoff.Quick Start
Configuration
Error Codes
Retry Strategies
Backoff Algorithm
Exponential backoff with jitter
- Attempt 1: 1s (±25%).
- Attempt 2: 2s (±25%).
- Attempt 3: 4s (±25%).
- Attempt 4: 8s (±25%).
- Attempt 5: 16s (±25%). Maximum total delay: ~31 seconds for 5 retries
Code examples
Best Practices
Production recommendations
Follow the following advice for a best production setup:- Use
count: 2-3for balance of reliability and speed. - Always include
429(rate limits) inon_codes. - Monitor retry rates to detect systemic issues.
- Implement circuit breaker for persistent failures.
Error handling
Troubleshooting
High retry rates- Check if you’re hitting rate limits frequently.
- Verify API keys have sufficient quotas.
- Monitor provider status pages for outages. Slow response times
- Reduce retry count for latency-sensitive apps.
- Use shorter timeout values with retries.
- Consider fallbacks for faster alternatives. Still getting errors
-
Check if error codes are in
on_codeslist. - Verify retry count isn’t exhausted.
- Review provider-specific error documentation.
Monitoring
Track these retry metrics:Limitations
- Increased latency: Retries add delay (up to 31s for 5 attempts).
- Cost implications: Failed requests may still incur charges.
- Rate limit consumption: Each retry counts against quotas.
- Limited retries: Maximum 5 attempts to prevent excessive delays.
- Non-retryable errors: 4xx client errors are not retried.
Advanced Usage
Environment-specific configs:Fallbacks
Automatically switch to a different model when the primary fails.Quick Start
Configuration
Trigger Conditions
Fallbacks activate on these errors:Best Practices
Use a maximum of 3 fallback models. Order them by preference or cost, and choose models with similar capabilities.Code examples
Limitations
- Response consistency: Different models may return varying output styles.
- Parameter support: Not all providers support identical parameters.
- Cost implications: Failed requests may still incur charges from the primary provider.
- Latency impact: Sequential attempts add processing time.
- Provider dependencies: Requires API keys for all fallback providers.