Quick Start
How It Works
On transient errors (503, timeout, model overloaded), the agent retries the same turn against the next model infallback_models. Successful calls stay on the primary model.
Failover fires on retryable errors classified by the LLM error classifier and covers every turn shape — non-streaming, streaming, tool-iteration turns, reflection turns, and their async equivalents. A 503 on a streaming chunk pushes the same turn to the next model in fallbacks; the user sees continuous output, not a failure.
Configuration Options
| Option | Type | Default | Description | |---Model Fallback keeps your agent answering by automatically retrying on alternate models when the primary model is overloaded or unavailable.Streaming, tool-iteration and reflection turns route through the same failover engine as plain single-shot calls (unified in PraisonAI PR #2665). You don’t need a separate
fallbacks= setting for streaming paths.Best Practices
Put a cheap same-provider fallback last
Put a cheap same-provider fallback last
Useful for rate limits, not full provider outages — a cheap model on the same API may still fail if the provider is down.
Order by latency and cost
Order by latency and cost
Fallback runs the same prompt; a much weaker model may return a worse answer, not a missing one.
Limit chain length to 2–3
Limit chain length to 2–3
Longer chains delay user-visible errors without improving success rates much.
Use provider prefixes when mixing
Use provider prefixes when mixing
LiteLLM-style names (
anthropic/..., openai/...) route credentials correctly across providers.Related
LLM Configuration
Endpoints, API keys, and auth headers.
Models
Choosing models for agents.
Model Router
Dynamic model selection policies.
Rate Limiter
Throttle requests before they fail.

