Fallback chains

A fallback chain is the ordered list of providers behind a tier — a tier and its chain are the same thing, name and contents. It is the single feature that keeps a long agent task from dying on one rate-limit.

The idea

You call a tier like ultra. Behind it you have set an order, for example:

1. Claude (subscription)
2. GPT (API key)
3. Gemini (API key)

OpenLLM tries the first. If it is down, rate-limited, or the request is over that model's context window, OpenLLM moves to the second, then the third, and returns the first good answer. Your request is never dropped in the process, and your tool never sees the failure.

Setting one up

Go to Configuration → Fallback chains in the dashboard. Each chain is a named alias with an ordered list of models behind it.

Edit or rename a preset tier (lite, plus, ultra), or click New chain to create your own alias for a specific job — the name is yours to pick. You can reorder any time, and because your tools only ever reference the chain name, no tool config has to change when you do.

A practical pattern

Put a subscription account first to keep everyday cost near zero, then a metered API key second as the always-available backstop:

1. ultra → Claude subscription, then Anthropic API key, then a Qwen or Gemini model as a third catch.

Most days you ride the subscription. On the day Claude is at capacity, the task finishes anyway on the API key. The request is recorded under whichever model actually answered it, so a run that fell back to the API key shows up under that model in the dashboard.

Pinning a single model

When you do not want any fallback, skip the tier and call the model by its full id (for example openai/gpt-...). OpenLLM will use exactly that model and not substitute anything.