A customer support platform streams Claude responses to end users via SSE (Server-Sent Events). The platform proxies Claude's streaming API through its own backend. Engineers report that when Claude's API returns a 500 error mid-stream — after tokens have already been sent to the customer — the platform's error handling code attempts to send an HTTP 500 status, which fails because the HTTP response was already committed with a 200 header. What is the correct architectural pattern for handling mid-stream errors?

Once an HTTP 200 response with streaming headers is committed, the HTTP status code cannot be changed. Mid-stream errors must be communicated in-band via the event stream itself. The standard pattern is to define an error event type in the SSE protocol — e.g., event: error\ndata: {"code": 500, "message": "..."} — that the client handles gracefully. This allows the client to display a partial response with an error notice, retry the request, or show a graceful fallback. Option A (full buffering before sending) eliminates the streaming UX benefit — users see a blank screen until the full response completes, which defeats the purpose of streaming. Option C relies on EventSource auto-reconnect, but Claude's stateless API won't resume generation mid-stream — it would restart from the beginning. Option D (polling) solves the delivery problem but eliminates streaming latency benefits.