Top 5 Ways to Keep Claude Code Working Through Rate Limits, 529 Errors, and Outages

TL;DR

• Claude Code stops for four different reasons: a 429 rate limit, a 529 overloaded error, a provider outage, or a plan usage limit. Each needs a different fix.
• Claude Code already retries transient failures up to 10 times with backoff, and a fallback model chain can switch to another Claude model when one is overloaded.
• Client-side settings cannot fix a full provider outage or team-wide rate limits. A gateway that rotates API keys and fails over to Claude on Bedrock or Vertex can.
• Bifrost routes Claude Code through one endpoint and handles key rotation, retries, and cross-provider fallbacks behind it.

When Claude Code is down, it is rarely a single problem: an overloaded model, an exhausted API key, an Anthropic incident, and a used-up subscription window all look like "Claude stopped working." Bifrost, the open-source AI gateway built by Maxim AI, is the best choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability, and it keeps Claude Code running by failing over across keys and providers. This guide covers five ways to keep Claude Code working through rate limits, 529 errors, and outages.

Why Claude Code Stops: 429s, 529s, Outages, and Usage Limits

Claude Code stops when its model provider refuses or fails a request and its own retries run out. The message tells you which of four causes you hit, and the cause decides the fix. Anthropic's Claude Code error reference lists each message in full.

Figure 1: Each error has a different cause, so each needs a different fix.

• 429 Request rejected: you hit the rate limit on your API key, Bedrock project, or Google Cloud project. Our guide to managing Claude rate limits explains the tiers.
• 529 Overloaded: the API is at capacity across all users. A 529 is not your usage limit and does not count against your quota, and capacity is tracked per model.
• 500, timeouts, and outages: an incident or network failure on the provider side. Check status.claude.com, or the provider status page named in the message.
• Session or weekly limit: a Claude subscription's rolling usage allowance ran out, and Claude Code blocks requests until the reset time.

A single developer usually sees these as occasional interruptions. A team running Claude Code across dozens of engineers and CI jobs hits them far more often, which is why Claude Code usage limits become a platform problem, and why teams tackle LLM rate limits and outages with an AI gateway.

The 5 Ways at a Glance

The table compares the five approaches by which failures they cover and who sets them up.

Client-side settings and gateway failover work together. Retries and fallback models absorb short blips on one machine; a gateway handles anything that needs a different key or a different provider. Our production guide to retries, fallbacks, and circuit breakers covers the same layering for any LLM app.

Figure 2: Client-side retries and fallback models handle short blips; a gateway handles rate limits and full provider outages.

1. Route Claude Code Through Bifrost for Key Rotation and Provider Failover

The Bifrost AI gateway keeps Claude Code working by retrying, rotating API keys, and failing over to another provider before an error ever reaches the developer. Claude Code connects to Bifrost's /anthropic endpoint, and Bifrost routes each request to any of 25+ providers and 10,000+ models with 11 microseconds of overhead at 5,000 RPS (benchmarks).

Best for: Bifrost is built for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. It serves as a centralized AI gateway to route, govern, and secure all AI traffic across models and environments with ultra low latency. Bifrost unifies LLM gateway, MCP gateway, and Agents gateway capabilities into a single platform. Designed for regulated industries and strict enterprise requirements, it supports air-gapped deployments, VPC isolation, and on-prem infrastructure. It provides full control over data, access, and execution, along with robust security, policy enforcement, and governance capabilities.

How Bifrost handles 429s, 529s, and outages

Bifrost classifies every failed attempt and responds to each class differently, as described in its retries and fallbacks documentation:

• 429 rate limit: Bifrost rotates to another API key in the provider's pool and still applies backoff, because account-level quotas are often shared across keys.
• 529 overloaded and 5xx errors: Bifrost treats them as transient, keeps the same key, and retries with exponential backoff and jitter.
• Provider outage: once the primary provider's retries are exhausted, Bifrost moves to the next provider in the fallback chain, and each fallback gets its own full retry budget.

Figure 3: Claude Code sees one endpoint; Bifrost retries, rotates keys, and changes provider behind it.

The most useful fallback for Claude Code is the same Claude model on a different cloud. A routing rule can match Claude Code traffic and fall back from the Anthropic API to Claude on AWS Bedrock and Google Vertex:

{
  "governance": {
    "routing_rules": [
      {
        "name": "Claude Code failover",
        "enabled": true,
        "cel_expression": "headers[\"user-agent\"].startsWith(\"claude-cli\") && model == \"claude-sonnet-4-6\"",
        "targets": [
          { "provider": "anthropic", "model": "claude-sonnet-4-6", "weight": 1 }
        ],
        "fallbacks": [
          "bedrock/global.anthropic.claude-sonnet-4-6",
          "vertex/claude-sonnet-4-6"
        ],
        "scope": "global",
        "priority": 0
      }
    ]
  }
}

The rule matches only Sonnet requests from Claude Code, so Opus and Haiku requests keep their own models; add one rule per model family with its own fallbacks. Retries are off by default in Bifrost, so set max_retries in each provider's network_config (for example 3, with the default 500 ms initial and 5,000 ms maximum backoff). Key rotation on 429s needs max_retries above 0 and more than one key configured for the provider. Teams that prefer configuring this per virtual key can attach several providers to the key, and Bifrost builds an automatic fallback chain ordered by weight, as described in our guide to adaptive load balancing and automatic fallbacks. Our guide to routing Claude Code through AWS Bedrock with Bifrost covers the Bedrock side of the setup.

What else keeps Claude Code sessions stable

• Session affinity: Claude Code sends x-claude-code-session-id on every request, and Bifrost keeps each session on the provider and key that served it, so prompt caches stay warm between turns.
• Circuit breaker (Enterprise): reroutes a provider and model to a fallback when response headers signal degradation, with a configurable cooldown that can be read from a header such as retry-after-ms.
• Adaptive routing (Enterprise): ranks providers and keys on live traffic, sends more requests to healthy ones, and holds back keys a provider refuses. See what adaptive load balancing is.
• Per-developer limits: virtual keys with budgets and rate limits stop one runaway agent from exhausting the organization's provider quota and causing 429s for everyone.

Developers point Claude Code at Bifrost with two settings, or launch it through the Bifrost CLI with bifrost claude. For laptops where developers might bypass the gateway, AI Gateway + Bifrost Edge (alpha) routes desktop and coding-agent traffic through Bifrost at the endpoint.

2. Configure a Claude Code Fallback Model Chain

A fallback model chain lets Claude Code switch to another model when the primary model is overloaded or unavailable, instead of failing the turn. It is the fastest fix for 529 errors on one model, because capacity is tracked per model. Anthropic documents the feature in its model configuration guide.

Set a chain for one session with a flag, or persist it in settings:

claude --fallback-model sonnet,haiku

{
  "fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
}

Key behavior to know before relying on it:

• Scope: the switch lasts for the current turn only, and the next message tries the primary model again.
• Length: chains are capped at three models after duplicates are removed.
• Errors covered: overloaded, unavailable, and other non-retryable server errors. Rate-limit, authentication, billing, and request-size errors do not trigger the chain.
• Visibility: /status does not display the chain; the notice shown at the first switch is the only sign it is configured.
• Subagents: the chain also applies to subagents, which continue on whichever model accepts the request.

A fallback chain stays within one provider, so it does not help when the Anthropic API itself is down. For that, combine it with automatic failover across providers.

3. Tune Claude Code's Built-in Retries

Claude Code retries transient failures up to 10 times with exponential backoff before showing an error. That covers server errors, overloaded responses, timeouts that arrive before any output streams, and temporary 429 throttles. Tuning the retry settings helps most in CI jobs and long unattended runs.

For an overnight CI job, a watchdog with a cap keeps the run alive through a capacity spike without hanging forever:

export CLAUDE_CODE_RETRY_WATCHDOG=1
export CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS=1800000
claude -p "run the test suite and fix failing tests"

Longer retries only wait out a problem; they never route around it. When the same model on the same provider stays overloaded, retries end in the same error, which is where a fallback model or a gateway takes over. For how this fits CI pipelines at scale, see Claude Code in production with access control and cost limits.

4. Run Claude on a Second Cloud Provider

Claude models are available on the Anthropic API, Amazon Bedrock, Google Cloud's Agent Platform (formerly Vertex AI), and Microsoft Foundry. Each runs under its own account, quotas, and status page, so a developer can switch Claude Code to a cloud provider when the Anthropic API has an incident. Our overview of using Bedrock, Vertex, and Anthropic models through Bifrost explains how the providers differ.

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
claude

CLAUDE_CODE_USE_VERTEX=1 does the same for Google Cloud, together with your project and region settings. Claude Code then uses that provider's model IDs and shows that provider's status page in its error messages.

Best for: individual developers and small teams that already have AWS or Google Cloud access and want a manual escape route during an Anthropic incident.

The limitation is that the switch is manual and per machine. Every developer has to change their environment, restart, and lose the session's prompt cache, and each cloud needs its own credentials on every laptop. A gateway does the same switch automatically and centrally. Our guide to running Claude Code on Bedrock, Vertex, or your own models compares the two setups.

5. Manage Usage Limits and Concurrency

Some Claude Code interruptions are self-inflicted: a plan's session limit runs out, or too many parallel subagents push an API key over its rate limit. Managing usage and concurrency prevents those before any failover is needed.

• Check limits early: /usage shows plan limits and reset times, and the rate_limits fields in a custom status line show the remaining allowance continuously.
• Switch model family: the session and weekly limits are shared across models, but the Opus and Sonnet limits apply per family, so /model keeps you working when only one family is exhausted.
• Wait automatically: in an interactive subscription session, Claude Code can wait for the reset and continue the interrupted task; the Desktop app offers an auto-continue checkbox for session limits.
• Check the credential: for 429s, run /status to confirm the active credential. A stray ANTHROPIC_API_KEY can route requests through a low-tier key instead of your subscription.
• Reduce concurrency: large subagent fan-outs can exhaust both the weekly allowance and the per-key rate limit; run fewer in parallel for high-volume work.

Best for: individual developers on Claude Pro or Max plans, and anyone whose interruptions come from usage rather than provider capacity.

For teams, per-developer visibility matters more than per-session tips. Our guides to governing Claude Code usage across engineering teams and monitoring Claude Code token usage show how to attribute usage before it turns into rate limits.

How to Choose the Right Fix

Choose based on the error and how widely it happens. A plan usage limit needs usage management. An occasional 529 on one machine needs a fallback model chain and retry tuning. Repeated 429s or outages across a team need gateway failover, as covered in our comparison of AI gateways for multi-provider failover and load balancing.

Figure 4: Individual blips need client settings; team-wide limits and outages need a gateway.

Most teams end up using several of these together: a fallback chain and retry settings distributed through managed settings, plus a gateway that every developer's Claude Code points at. The Claude Code gateway explainer covers how routing, governance, and cost control fit in one layer.

Frequently Asked Questions

What does a 529 overloaded error mean in Claude Code?

A 529 overloaded error means the API is temporarily at capacity across all users for that model. It is not your usage limit and does not count against your quota. Claude Code retries it automatically, and you can switch models with /model or configure a fallback model chain to keep working.

What is the difference between a 429 and a 529 error?

A 429 means your API key, workspace, or cloud project hit its rate limit, so the fix is on your side: a higher tier, less concurrency, or another key. A 529 means the provider is overloaded for everyone, so the fix is waiting, switching models, or failing over to another provider.

Why is Claude Code down when status.claude.com shows no incident?

Claude Code can stop without a public incident when your own rate limit, plan usage limit, or credential is the problem. Run /status to check which credential is active and /usage to check plan limits. A local network or proxy issue can also cause timeouts that look like an outage.

Does a fallback model work for rate limits?

No. Claude Code's fallback model chain covers overloaded and unavailable models but not rate-limit, authentication, or billing errors. To survive 429s, spread traffic across more keys or providers, which a gateway such as Bifrost does with automatic key rotation.

Can Claude Code fail over to Bedrock automatically?

Not on its own. Claude Code connects to one provider per session, set by environment variables. Automatic failover from the Anthropic API to Claude on Bedrock or Vertex requires a gateway in front of Claude Code, such as Bifrost with a fallback chain in a routing rule. See enterprise AI gateways for automatic fallback routing.

How do I keep Claude Code running in CI during outages?

Set CLAUDE_CODE_RETRY_WATCHDOG=1 with a maximum wait so jobs ride out capacity errors, configure a fallback model chain, and point Claude Code at a gateway that fails over across providers. That combination covers short spikes, model-level overloads, and full provider incidents.

Keep Claude Code Running with Bifrost

Retries and fallback models handle short blips, but rate limits across a team and full provider outages need a layer that can change keys and providers. Bifrost gives Claude Code one /anthropic endpoint that rotates API keys on 429s, retries 529s, and fails over to Claude on Bedrock or Vertex, with load balancing across AI workloads and per-developer budgets built in. To see it with your own Claude Code traffic, book a demo with the Bifrost team.