Anthropic returned 529 overloaded. Claude Code told users their org was out of credit. The bridge layer is where the real fix lives.

A cluster of overload incidents on the Anthropic API surface that ran on a load-shedding signal: HTTP 529 'overloaded'. The status code is documented behavior for Claude when traffic exceeds the available capacity for a tier. Independent users reported the symptom hitting hardest in three windows: late Friday May 15 PT, mid-day Saturday May 16 PT, and Sunday morning May 17 PT, with the longest visible tail on Sunday. The pattern across the three windows is the same: requests succeed at the network layer, the body is JSON, the type field is 'error', the code field is the integer 529, and the message reads 'Overloaded'. It is not a billing event and it is not a per-user rate limit; it is the platform telling the client to back off because shared capacity is saturated.

Because most Claude Code clients in May 2026 treat any non-200 from the Anthropic API as terminal for the turn and then map it to whichever recovery surface they happen to have. Out-of-credit messaging is a Team-and-Enterprise affordance bolted to the wallet layer that is supposed to fire only when the org's extra usage pool is empty. A naive client that does not branch on the error code at the bridge layer surfaces a wallet message when the actual error is 529. That is what users saw: an outage-shaped error decorated as a billing prompt, with a 'let your admin know' phrase attached that has nothing to do with what failed.

Anthropic does maintain status.anthropic.com and publishes incident reports for API events; the public record of the weekend is several elevated-error and degraded-performance incidents on the Claude API and on the Claude.ai surface, all tied to the same overload signal. There was no separate blog-post-style postmortem at the time of writing this page; the canonical primary source is the incident timeline on the status page itself plus the response code semantics documented at docs.anthropic.com on the errors page. The fact that there is no glossy post is the right read: 529 is documented expected behavior for capacity events, not a regression.

Two reasons. First, Claude Code is now the primary developer surface for a meaningful slice of the engineering audience; an outage that disrupts a few hours of agent work for thousands of people is more visible than an equivalent dip on a chat product. Second, the failure mode in most clients was misleading. Users were not told 'Anthropic is overloaded, retry in a minute'; they were told 'your org is out of extra usage' or 'your model has been switched' or 'session ended'. Misleading errors generate quoted screenshots. Quoted screenshots are how things go viral. The cluster of posts on X on May 17 was the same handful of screenshots and the same shape of complaint repeated.

The bridge layer (acp-bridge in the Fazm repo) added explicit 529 handling on the streaming request to Anthropic. The raw 529 is caught at the bridge, classified as a transient overload, and an exponential backoff retry is fired on the same provider and the same session ID instead of bubbling the error to Swift. The streaming socket to the Mac app stays open through the retry, so the active chat window does not flip to a fallback model and does not abort. Sibling chat windows in the same Fazm process are completely untouched because each window holds its own session in the bridge map. The user-visible effect on May 15 to 17 was that Fazm windows printed a small 'overload, retrying' line and then continued; clients without the same branch printed 'out of credit' and stopped.

In the public mediar-ai/fazm repo on GitHub. The bridge file is acp-bridge/src/index.ts; the 529 branch sits near the streaming retry loop alongside the existing 429 and 5xx handling. The dated release line is in CHANGELOG.json under version 2.9.18 with date 2026-05-15. The CHANGELOG.json entry reads, paraphrased, that 529 overloads from Anthropic no longer trigger a fallback mode switch and no longer abort other open chat windows. The Swift side (the macOS app) was unchanged for v2.9.18; the fix is fully bridge-layer, which is part of why it shipped the same day as the first overload window without needing a notarized binary release.

Both, but in different ways. The 529 itself is correct behavior on Anthropic's side; capacity events have to surface as an error rather than a silent timeout, and 529 is a documented signal. The way most Claude Code clients translate that signal into a user-visible message is a client problem. There is no infrastructure reason a 529 has to read as a billing prompt; the only reason it does is that the recovery surface for capacity events on Team and Enterprise plans was built before agent loops were common, and the heuristic for 'show the out-of-credit page' did not get tightened when 529 became more frequent. The fix lives in clients.

It surfaces it honestly. The retry banner says 'overload, retrying' with the provider name and the retry count, and the active chat does not pretend it succeeded. If the overload persists past the configured retry budget the chat shows a clear 'Anthropic is overloaded, try again in a minute' message instead of a wallet prompt. The session is preserved on disk either way, so if you close the window you can reopen the conversation later. The point is not to mask the outage; the point is to name it correctly and keep the rest of the workspace usable while it lasts.

Three moves. First, check status.anthropic.com to confirm the cause; if there is an open incident the wallet-shaped error you are seeing is wrong. Second, if your client supports it, switch the affected chat to a different provider for the moment (a wrapper that supports Codex via codex-acp lets you do that per chat without changing IDEs). Third, if your workflow is session-shaped, prefer a client that keeps the chat on disk so the conversation survives the outage; resuming a chat after Anthropic recovers is preferable to losing the thread. The fourth, longer-term move is to bring your own Anthropic account (Pro or Max) into the wrapper so the wallet branch never fires for you in the first place.

Voice transcription on Fazm runs on-device via WhisperKit. The transcript becomes text the moment you release the hotkey; the 529 only enters the picture when the agent step that follows sends the prompt to Anthropic. So during an outage your voice still types into the chat field locally, but the agent's reply is what stalls or retries. If you are dictating long instructions, the prompt is captured and queued, and the bridge replays it on retry once Anthropic recovers; you do not have to redictate. That is also the bridge-layer fix, not a UI patch.