Build a Fallback Chain So Your Agent Never Goes Down When a Model Does
How to set up a reorderable fallback chain in Settings so your agent automatically moves to the next model when its first choice is unavailable.
Model providers have outages. They also deprecate models with a few months' notice and change pricing without much warning. If your agent's behavior depends on one specific model always being reachable, any of those events becomes your outage too. The AI Models page in Settings gives you a direct answer: a fallback chain you control.
Setting one up
On the AI Models page, you build an ordered list of models — your first choice, then whatever should be tried next if that one fails, and so on. The UI has explicit reorder controls (move a model up or down the list) and lets you add or remove entries individually, so building the chain is a matter of arranging models in priority order rather than editing configuration by hand.
There's a hard cap on how long a chain can get: eight models. That's enforced at the database level too, not just in the UI, so the ceiling isn't something a bug in the interface could quietly let you exceed.
What "fallback" actually means here
When a request against your first-choice model fails, the system moves to the next entry in your chain automatically, without you needing to notice the failure and manually switch anything. The chain exists specifically so a provider outage or a deprecated model doesn't turn into your agent going silent — it turns into your agent using its second or third choice for a while instead.
A wrinkle worth knowing about
A few providers — your own custom endpoint, OpenRouter, and Cloudflare's own model catalogue — can't be queried for "what models do you currently offer" the way most providers can. Those show up in your chain options differently than providers with a listable catalogue, since the system can't validate model names against them the same way. It doesn't stop you from using them; it just means the platform can't double-check a model name is real before you add it.
Where this fits with tiers
A fallback chain is about resilience — what happens when your chosen model is unreachable. It's a related but separate control from tiers, which decide what model gets used by default in the first place. If you haven't read it yet, the companion piece on tiers versus pinned models explains the difference and why you generally want both configured, not just one.