# 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.