Anthropic SSE error events: after HTTP 200, errors arrive as stream events, not status codes

TL;DR: On a streaming response, the API can fail after returning 200. The error arrives as an SSE event named error, and your HTTP error handling never sees it. Handle error events explicitly: parse the inner error type and route it to the same handler you use for that type over HTTP (overloaded_error gets the 529 backoff treatment). Handle unknown event types gracefully.

Mid-stream errors: handle the event, not the status

When streaming over server-sent events, an error can occur after the 200 response. Standard HTTP error handling does not apply. Anthropic documents the error event shape: an event named error carrying a JSON object with type error and an inner error object holding type and message. During high usage this is often an overloaded_error, the streaming twin of HTTP 529.

What to do

1. In your SSE loop, branch on the event name. Handle error events explicitly: parse the inner error type and route it to the same handler you use for that type over HTTP (overloaded_error gets the 529 backoff treatment).
2. Handle unknown event types gracefully. Anthropic's versioning policy allows new event types; a strict parser that crashes on an unknown event turns a harmless addition into an outage.
3. For recovery after an interrupted stream: save everything received before the error. On Claude 4.6 and later models, resume with a new request whose user message contains the partial response plus an instruction to continue from where it left off. On Claude 4.5 and earlier, the partial response goes in as the start of a new assistant message instead.
4. Know the limits of resume: tool_use and extended thinking blocks cannot be partially recovered. Resume streaming from the most recent text block.

The trap

Writing a stream consumer that only checks the HTTP status. The 200 already happened, so every mid-stream failure is invisible to that code and the stream just ends. The other trap: using the 4.5-era resume shape (partial text as an assistant message) on 4.6+ models, where the documented pattern is a user message asking to continue.

Checklist

• Every SSE consumer needs three branches: data events, error events, and unknown events (log and continue).
• After an error event, decide: resume from the partial response, or retry the whole request. Do not do both.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Anthropic SSE error events.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Anthropic's streaming reference documents error events (event named error, inner error type/message, e.g. overloaded_error as the streaming twin of 529), graceful handling of unknown event types, and the 4.5 vs 4.6+ error recovery patterns. Verified live at https://platform.claude.com/docs/en/api/messages-streaming.