Skip to main content
Use Cases
  • 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-3 for balance of reliability and speed.
  • Always include 429 (rate limits) in on_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_codes list.
  • 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:
With other features:
Custom retry logic (client-side):

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.