Claude Code Overloaded? Set a Fallback Model

A fallback model is a backup Claude Code switches to on its own when your main model is overloaded or unavailable — instead of stopping with an error. You configure it once, and the next time the servers are slammed, the work simply continues on a different model. This is the calm fix for the dreaded '529 Overloaded' message.

I'm Evgeny, and I build with Claude Code every day — which means I hit overload errors at exactly the wrong moments, usually three steps into something I don't want to redo. For months my reflex was to run /model and switch by hand. Then I set up a fallback chain once, and the interruptions mostly disappeared. Here's the whole setup, in plain words.

What does '529 Overloaded' mean in Claude Code?

It means the servers for that specific model are busy for everyone right now — not that you did anything wrong, and not that you ran out of your plan. Because capacity is tracked per model, a model that's overloaded for you is often fine on a different one. The manual workaround has always been to run /model and pick another model. A fallback model just does that switch for you, automatically, the moment it's needed.

What is a fallback model, exactly?

It's a list of one or more backup models Claude Code tries, in order, when the primary one is overloaded, unavailable, or hits another server-side error. It shows a small notice when it switches so you're never confused about which model answered. The switch lasts for the current turn only — your next message tries your primary model first again, so you're not silently demoted for the rest of the session.

claude --fallback-model sonnet,haiku

How do I set a fallback model permanently?

Add a fallbackModel array to your settings file — ~/.claude/settings.json for all your projects, or .claude/settings.json for one project. You can list friendly aliases like sonnet and haiku, or full model names. Easiest of all: just ask Claude to do it for you.

{
  "fallbackModel": ["sonnet", "haiku"]
}

Which models should I put in my fallback chain?

When does the fallback NOT kick in?

This is the part people get wrong, so let's be clear. Fallback only triggers on overload, an unavailable model, or a server error. It deliberately does NOT trigger for login problems, billing issues, request-too-long errors, or — importantly — when you've hit your plan's usage limit. A fallback model is not a way to keep working past 'You've hit your session limit'; that's a different message with a different fix.

Set this once and you mostly stop thinking about overloads — which is the point. The best reliability tricks are the ones you configure on a calm afternoon, so the busy servers on a deadline evening become someone else's problem, not yours.