Every model provider goes down eventually: the only question is whether your agents go down with it. For an always-on squad, the answer should be no, and the mechanism is an ordered fallback chain: backup models each agent tries automatically when the primary fails, so a provider's bad hour costs you nothing but a log line.
4+ hours
is how long ChatGPT and OpenAI's API were down in a single December 2024 incident. A squad with exactly one model provider was down with it; a squad with a fallback chain kept working.
Source: CNBCiShort answer
Chatbot users retry after an outage; a 2am scheduled task cannot. In Squad (formerly MissionControlHQ), you give agents an ordered list of fallback models: if the primary is unavailable (outage, rate limit, or expired connection), the task runs on the next model in the chain instead of failing. The list is set once for the whole workspace, in AI Tokens; span providers (ChatGPT, Claude, Gemini, Grok, and nine more) if you want full-outage protection, not just rate-limit protection.
Key takeaways
| Principle | What it means in practice |
|---|---|
| Their outage becomes your outage | Unless something catches the failure automatically |
| Three failures, one fix | Outage, rate limit, expired auth: the chain catches all |
| One list, set once | One workspace fallback order in AI Tokens, Model routing |
| Cross-provider = real protection | Same-provider chains die with the provider |
| Visible, not silent | Runs shows which model ran; frequent fallback = fix the primary |
The task completes either way; only the log line differs.
Task starts, primary unavailable
Outage, rate limit, or an expired connection: identical from the task's perspective.
Chain advances
The agent tries the next model in its ordered list, automatically.
Work completes
The 2am run finishes at 2am, not after a human wakes up and retries.
Run history records it
You see which model actually executed, and how often the chain fires.
The 2am problem
A human using a chatbot experiences an outage as an inconvenience: the page errors, they sigh, they come back after lunch. The retry logic is the human.
An always-on squad has no such luxury. Its work runs on schedules and triggers: the 2am competitor sweep, the 6am daily brief, the inbound email that arrives at midnight. When a provider incident lands during those windows, there is no one present to notice, retry, or reroute. Without a fallback, the failure mode is the worst kind: silently skipped work, discovered hours later as a missing brief or an unanswered email, when the outage itself is already over.
This is the structural difference between using AI and operating on it. The moment agents carry real recurring responsibilities, your provider's uptime becomes your uptime, unless you break that coupling deliberately.
Three failures that look identical
Full outages get the headlines, but a chain earns its keep on quieter failures too. From a running task's perspective, three distinct problems present identically, "the primary model is unavailable":
- Provider outages. Rare but real, and they last hours, not seconds. No amount of retrying the same provider helps.
- Rate limits. Busy hours, burst workloads, or a misbehaving loop can exhaust a plan's throughput. The provider is up; your access temporarily is not.
- Expired connections. OAuth credentials lapse, tokens age out. Nothing is "down", but every call fails until someone re-authenticates.
The elegance of the chain is that one mechanism covers all three. The task does not diagnose which failure occurred; it advances to the next model and completes, provided that model sits on a connection the failure did not also take out (the reason chains should cross providers, below). Diagnosis happens later, by a human reading the run history, on their schedule instead of the outage's.
How fallback chains work
In Squad, the chain is an ordered list of models configured in AI Tokens, under Model routing. If a run on the default model fails or hits a rate limit, it automatically tries the next model in the chain instead of failing the task, then the next, until one answers.
Order encodes preference: put the model you want doing the work first, the acceptable substitute second, the break-glass option last. The chain should read as a policy statement: "this squad runs on our flat-rate ChatGPT plan; if that fails, use Claude; if that fails, GLM." Each hop trades a little preference for continuity, which is exactly the trade you want made automatically at 2am.
One list: protect everything by default
The detail that separates a reliability feature from a reliability checkbox: the fallback order is one list for the whole workspace. Every run that uses the default model starts there and, when it fails or hits a rate limit, moves down the list. You set it once, and it covers the work that runs on the default model: agents without a pinned model, their heartbeats, and the scheduled tasks you create next month and forget to configure.
Per-agent pins exist for the exception, not the rule: pin a different model for one agent when it needs a different primary than the rest of the squad (a writing lane pinned to Claude, say), and each scheduled task can set its own model. The docs describe no per-agent fallback list, so keep pins rare and let everything else run on the default. Default-on protection is the difference between "we configured failover for the important tasks" and "nothing in this workspace fails because one vendor had a bad hour": the second one is the goal, and it survives your own forgetfulness.
One provider or several?
A chain within a single provider (two ChatGPT-served models, say) survives rate limits and some degraded-service incidents. It does not survive the December-2024 kind, and it does not survive expired auth either: an expired connection takes every model behind it down together, exactly like a full outage does.
Real outage protection means the chain crosses providers. Squad is bring-your-own-AI across thirteen providers (ChatGPT, Claude and Claude Code, Grok, Gemini, GitHub Copilot, Kimi, MiniMax, Z.AI, Qwen Cloud, OpenRouter, Cloudflare Workers AI, and OpenCode), so a chain can span any of them: flat-rate ChatGPT as the workhorse primary, Claude as the backup, GLM as the deep reserve. On the Claude card, Anthropic, not Squad, decides whether that usage counts against the plan's limits or bills as Extra Usage, so check how your Claude account bills before you count on it as a backup that costs nothing while idle; subscription-backed reserves (a MiniMax or GLM plan) carry their plan price even while idle, so count that standing cost before adding one purely as insurance.
An outage in practice
Walk the December scenario through a prepared squad. At 3:16pm the primary provider starts erroring. The support agent's inbound triage hits the failure first: its call fails, the chain advances, the reply goes out written by the backup model. Nobody outside the run history can tell. Over the next four hours, the evening heartbeats, the competitor sweep, and two scheduled briefs all execute the same way: attempted on the primary, completed on the backup.
The founder finds out the next morning, reading the run history over coffee: forty-some runs stamped with the backup model, zero failed tasks, zero missed sends. Compare the unprepared version: forty-some silent failures, an inbox of unanswered email, and a rerun queue to triage. The difference was not heroics; it was one ordered list, configured once, months earlier.
Keeping fallbacks honest
Two habits keep chains trustworthy. Read the fallback frequency. A chain that fires once a quarter is insurance working; one that fires daily is a broken primary wearing a disguise, usually an expired connection or a chronically rate-limited plan. Runs shows the model and provider of every run in its Technical details; treat repeated fallback as a defect to fix, not a feature to admire. Keep Allowed models current. Model catalogs change, and only models on the Allowed models list can be picked anywhere in the workspace. Review that list and the fallback order together, so chains do not quietly rot into lists of dead entries.
Chain design cheat sheet
| Scenario | Best pick | Why |
|---|---|---|
| Whole squad on one flat ChatGPT plan | Workspace chain: ChatGPT primary, Claude backup | Flat rate does the work; the backup runs only during incidents. |
| Writing lane needs Claude | Pin Claude for that agent only | Different primary = the one honest reason for a pin; the fallback list stays workspace-wide. |
| Chain within one provider only | Add a second provider | Same-provider chains die with the provider. |
| Fallback firing daily | Fix the primary, don't admire the chain | Usually expired auth or a chronically exhausted plan. |
| New scheduled task created | Leave Model on Agent default (do nothing) | No extra override to keep in step with the squad's model plan. |
| A model is missing from a list | Turn it on in Allowed models | Only allowed models can be picked anywhere in the workspace. |
How many providers are in your chain?
- If one→covers model-specific limits only; account-level limits, expired auth, and outages all need a second provider
- If two or more→full-outage protection: order by preference
Where should the chain live?
- If the squad shares one primary model→the workspace default plus the fallback list
- If one agent runs a different primary→pin that agent's model; the fallback list stays workspace-wide
How often does fallback fire?
- If rarely: incidents only→working as designed
- If frequently→diagnose the primary: expired auth or exhausted plan
Frequently asked questions
The mechanism
What is a model fallback chain for AI agents? An ordered list of backup models an agent tries automatically when its primary model fails: outage, rate limit, or expired connection. Instead of the task failing, the agent runs it on the next model in the chain, and the human hears about it later instead of during.
What failures trigger a fallback besides full outages? Three common ones: provider outages, rate limiting during busy hours, and expired connections (an OAuth credential that lapsed). All three look identical from the task's perspective, the primary model is unavailable, and all three are caught by the same chain.
How do I know a fallback actually fired? Runs shows which model and provider executed each run, in the run's Technical details. Fallbacks should be visible after the fact, not silent forever: if a chain fires often, fix the primary.
The design
Why do always-on agent squads need backup models more than chatbots do? A human chatting hits an outage, sighs, and retries later. A squad running scheduled tasks overnight has no one to retry: a provider incident during a 2am run means silently skipped work unless a fallback chain catches it. Always-on operation turns provider reliability into your reliability.
Should every agent have its own fallback chain? No. Squad has one ordered fallback list for the whole workspace, set in AI Tokens under Model routing, so failover is configured once. What can differ per agent is the model: pin a different model for an agent only when it needs a different primary than the rest of the squad.
Does a fallback chain need multiple provider accounts? For real protection, yes: a chain within one provider survives rate limits, but an expired connection or a provider-wide incident takes every model behind that connection down together. Mixing providers, for example ChatGPT primary with Claude, MiniMax, or Z.AI backups, is what makes those survivable.
Sources
- CNBC: OpenAI says ChatGPT service has recovered after hours-long outage
- OpenAI: status page
- Squad: homepage, get started
- Related on this site: Why Squad, Mission Control for OpenClaw
Last updated: September 2026. Product capabilities verified against the Squad homepage (squad.so) and docs (squad.so/docs) as of September 2026.