Fallback chains

A fallback chain is the ordered list of providers behind a tier. 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 Config in the dashboard, pick a tier, and drag your connected providers into the order you want. Do this once per tier (lite, plus, ultra). You can reorder any time, and because your tools only ever reference the tier 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, and you see the fallback 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.