Skip to main content

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:
Fallback chain:
  1. OpenAI (primary)
  2. Azure OpenAI (if OpenAI fails)
  3. DeepInfra (if Azure fails)

Different Models

Fallback to different models:
Fallback chain:
  1. GPT-4o (best available provider)
  2. GPT-4o-mini (cheaper alternative)
  3. Claude Sonnet 4 (different model family)

Cross-Provider Fallback

Fallback across different cloud providers:
Fallback chain:
  1. AWS Bedrock (primary)
  2. Anthropic direct (if Bedrock fails)
  3. Google Vertex AI (if Anthropic fails)

Common Fallback Patterns

Try cheaper providers first, fallback to premium:
Pattern:
  1. DeepInfra (lowest cost)
  2. OpenAI standard (if DeepInfra unavailable)
  3. GPT-4o (best quality, highest cost)

Failure Scenarios

The gateway automatically retries on these failure types:
Provider rate limit exceeded
Exception: Helicone-generated 429s (escrow failure, rate limits) bail immediately without trying fallbacks.
Invalid or expired provider keys
Provider service unavailable
Request timeout
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:
Helicone 429s bail immediately:If Helicone returns a 429 (insufficient credits or rate limit), the request fails immediately without trying fallbacks. Add credits at helicone.ai/credits.

Fallback Best Practices

List the native provider first for best compatibility:
Mix low-cost and reliable providers:
2-4 fallbacks is usually sufficient:
If fallbacks trigger frequently:
  • Check provider status
  • Verify BYOK keys
  • Consider changing primary provider
  • Review rate limits
Monitor at Helicone Dashboard
Test fallbacks by:
  1. Using invalid BYOK keys temporarily
  2. Requesting rate-limited models
  3. Monitoring which providers succeed

Real-World Examples

Production-Grade Fallback

Cost-Optimized with Fallback

Regional Resilience

Streaming with Fallbacks

Fallbacks work seamlessly with streaming:
If the first provider fails, the stream automatically switches to the next provider.

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