overloaded_error mid-stream (529 after 200)

Anthropic’s overloaded_error (HTTP 529) can arrive after a request has already returned 200 and begun streaming, delivered as an SSE error event partway through the response. Your status-code retry logic already saw the 200 and moved on, so it never fires. The stream just stops. 200 OK is a lie here: the status promised success before the failure had happened.

What it looks like

The connection opens with a 200 and starts streaming normally. Partway through, an error event appears in the SSE stream instead of the expected completion:

event: message_start
data: {"type":"message_start", ...}

event: content_block_delta
data: {"type":"content_block_delta", ...}

event: error
data: {"type":"error","error":{"type":"overloaded_error","message":"Overloaded"}}

The HTTP status was 200 the moment the connection opened. The 529 lives in the stream, not in the response status, so anything checking response.status saw success.

Why it happens

Streaming responses commit an HTTP status as soon as the connection is established, before generation finishes. If Anthropic’s capacity is exceeded partway through, the overload is reported as an error event within the already-open stream rather than as a fresh HTTP status. This is common during demand spikes, especially just after a new model launch.

Why your monitoring can’t see it

Retry libraries and status-code dashboards inspect the HTTP status of the response. For a streamed request that status is 200, decided before the failure occurred. The 529 is a payload event, invisible to anything that does not parse the stream. Teams discover it as truncated answers and confused users, not as an alert.

How to detect and handle it

1. Parse errors from the stream, not just the status

Inspect SSE error events for overloaded_error. A 200 on a streamed request does not mean the request succeeded.

2. Retry on stream-level errors

Extend retry logic to trigger on a mid-stream 529, not only on a 529 HTTP status. Use backoff, since these cluster during capacity spikes.

3. Alert on the rate of mid-stream overloads

A rising rate signals a provider capacity event, often correlated with a recent model launch. Detect it before users churn.

4. Consider failover

When mid-stream overloads spike, route to an alternate model or provider until capacity recovers.

How Dstl8 detects this

Dstl8 reads the actual content of every log line, not just its status code, so this failure gets caught even though the request came back as a clean 200. We track how often it is happening and how that rate moves over time. When it climbs after a deploy or a model swap, Möbius flags it and ties it back to the change that introduced it. The failure your status dashboard cannot see becomes a first-class signal with a root cause attached.

Related patterns

References

• Catching Anthropic errors, including mid-stream overloads: how a 529 can arrive as a stream event after a 200.

Third-party API behavior, verified July 2026. Providers change this behavior over time; re-checked quarterly.