Skip to main content
A ready-to-run example is available here!
FallbackStrategy gives your agent automatic resilience: when the primary LLM fails with a transient error (rate limit, timeout, connection issue), the SDK tries alternate LLMs in order. Fallback is per-call — each new request always starts with the primary model.

Basic Usage

Attach a FallbackStrategy to your primary LLM. The fallback LLMs are referenced by name from an LLM Profile Store:

How It Works

  1. The primary LLM handles the request as normal
  2. If the call fails with a transient error, the FallbackStrategy kicks in and tries each fallback LLM in order
  3. The first successful fallback response is returned to the caller
  4. If all fallbacks fail, the original primary error is raised
  5. Token usage and cost from fallback calls are merged into the primary LLM’s metrics, so you get a unified view of total spend by model
Only transient errors trigger fallback. Non-transient errors (e.g., authentication failures, bad requests) are raised immediately without trying fallbacks. For a complete list of supported transient errors see the source code

Multiple Fallback Levels

Chain as many fallback LLMs as you need. They are tried in list order:
If the primary fails, fallback-1 is tried. If that also fails, fallback-2 is tried. If all fail, the primary error is raised.

Custom Profile Store Directory

By default, fallback profiles are loaded from .openhands/profiles. You can point to a different directory:

Metrics

Fallback costs are automatically merged into the primary LLM’s metrics. After a conversation, you can inspect exactly which models were used:
Individual token_usage records carry the fallback model name, so you can distinguish which LLM produced each usage record.

Use Cases

  • Rate limit handling — When one provider throttles you, seamlessly switch to another
  • High availability — Keep your agent running during provider outages
  • Cost optimization — Try a cheaper model first and fall back to a more capable one on failure
  • Cross-provider redundancy — Spread risk across Anthropic, OpenAI, Google, etc.

Ready-to-run Example

This example is available on GitHub: examples/01_standalone_sdk/39_llm_fallback.py
examples/01_standalone_sdk/39_llm_fallback.py
You can run the example code as-is.
The model name should follow the LiteLLM convention: provider/model_name (e.g., anthropic/claude-sonnet-4-5-20250929, openai/gpt-4o). The LLM_API_KEY should be the API key for your chosen provider.
ChatGPT Plus/Pro subscribers: You can use LLM.subscription_login() to authenticate with your ChatGPT account and access Codex models without consuming API credits. See the LLM Subscriptions guide for details.

Next Steps