Parallel Claude Code agents do not survive a Claude Code outage

The shape of the failure mode

When you run parallel Claude Code agents, what you have is one orchestrator process spawning many client connections, all bearing the same API key, all resolving the same hostname, all terminating at the same TLS frontend at Anthropic. There is no transparent fan out across providers. There is no hot standby. The redundancy you imagine you bought by spinning up four worktrees and a Task tool fanned out three deep is, from the upstream's point of view, a single tenant pushing a load-balanced burst at a single endpoint.

When that endpoint sneezes, all of your agents sneeze. The status page on May 8, 2026 logged three incidents inside one work day. Inside one of those windows, your fleet of parallel agents was serializing on the recovery, not chewing through tickets. Most of the advice that ranks for this query is some version of “wait, retry, reduce concurrency.” That advice describes how to be well-behaved under rate limits. It does not describe how to keep working when the upstream itself is broken.

The thing that helps is breaking the shared dependency. You do that by pointing the client at a different upstream. Two paths: a different gateway that speaks the Anthropic message format (corporate proxy, Copilot bridge, local LLM bridge, Bedrock or Vertex region), or a different model family entirely (GPT through Codex). The first path is one environment variable (ANTHROPIC_BASE_URL). The second is a backend toggle.

What helps and what does not

Six things you can do during an outage, ranked by whether they actually decouple your agents from the broken upstream.

The single line that does the rerouting

Fazm runs Claude Code under the hood through a small Node bridge called acp-bridge. When the Swift app spawns the bridge, it builds an environment for the child process. One conditional inACPBridge.swift checks the user-set customApiEndpointUserDefaults value. If it is non-empty, the bridge process inherits a redirected ANTHROPIC_BASE_URL and the Anthropic SDK happily uses it for every subsequent request.

The Settings UI for that field lives inDesktop/Sources/MainWindow/Pages/SettingsPage.swift around line 984. Placeholder text: https://your-proxy:8766. Help line: “Route API calls through a custom endpoint (e.g. local LLM bridge, corporate proxy, or GitHub Copilot bridge). Leave empty to use the default Anthropic API.” If you want to verify the wiring before trusting it during an actual outage, thecustomApiEndpoint string is searchable from the Fazm source tree at github.com/m13v/fazm.

Mitigation in four steps

What to do the next time the status page lights up while you are mid-task.

The Codex backend toggle

The harder failure mode is when none of the Anthropic-shaped upstreams are healthy and your alternative gateway is also flaky. That is the case when an inference layer bug propagates across fleets, which is what the May 6, 2026 “Elevated errors across multiple models” incident looked like. The honest answer there is to switch model families. Fazm has a separate setting for that.

In Desktop/Sources/MainWindow/SettingsSidebar.swift line 86, there is a search item registered with idadvanced.codex.toggle: “Codex Backend, Route GPT-5 family models through OpenAI’s Codex CLI”. Enable it and the model picker on the floating control bar gains GPT-5 family entries. Pick one from the same dropdown you use for Sonnet or Opus. The session continues without a restart, the running tools and prompts and conversation context stay attached. Underneath, the bridge has flipped from Anthropic to OpenAI. That is a real fallback to an independent platform with an independent status page, not a different SKU on the same fleet.

Combined with thecustomApiEndpoint override, you have two orthogonal moves: change the upstream (different gateway, same model family) or change the family (different vendor entirely). Most of the time the first one is enough. When it is not, the second one is.

Things this does not fix

Honest list. If the outage is at your edge (DNS resolver, captive portal, corporate proxy that you did not configure, a recently-rotated GitHub IP allowlist), no amount of upstream redirection helps because the redirection itself cannot leave your network. The May 7, 2026 incident affecting orgs with IP-based GitHub access restrictions is exactly this shape: Anthropic changed its outbound IPs, downstream firewalls denied the new ones, everyone’s parallel agents stopped. The fix in that case is at the firewall, not at the client.

Likewise, if a parallel-agent run is failing because the model is producing bad output during a regression rather than because the API is timing out, switching upstreams just gives you the same bad output from a different host. That is what 4xx-level “model quality” incidents look like; the right answer is wait or downgrade to a known-good version, not reroute.

And rerouting through a public Copilot bridge under load can hit the bridge’s own rate limits. The bridge is somebody else’s server. Treat it as a peer to api.anthropic.com, not as a guaranteed-up alternative.

The one-sentence version

Parallel agents do not give you redundancy against an upstream outage; only a different upstream does. Fazm exposes that different upstream as a text field in Settings and, when the field is not enough, as a backend toggle that swaps the entire model family. It is a desktop app for people who do not want to be editing dotfiles in the middle of an incident.