“Error in message stream” in ChatGPT — causes and how to fix it

The three actions for the first 90 seconds

Regenerate the response → reload the page (on mobile, fully close the app and reopen it) → sign out and sign back in. A one-off interruption is resolved by one of these three, and one-off is the normal case. If it always stops at exactly the same point, however, that indicates one of the specific causes below is acting rather than an isolated glitch.

First decide whether the problem is on your side

This is the step other troubleshooting lists skip, and the one that saves the most time. Open status.openai.com. If there is an active incident, no local adjustment will fix it and waiting is the only option. If nothing is listed, the cause is local and the next step narrows it down. Doing this check before changing settings prevents spending twenty minutes clearing caches during an outage.

Isolate the local cause from the outside in

Proceed in this order, because each layer rules out everything before it: (1) turn off the VPN and proxy; (2) open a private window — this removes extensions and cache at once; (3) try another browser or device; (4) switch networks. The layer at which it starts working again is the cause. If the error appears only in long threads, none of the four is at fault: move the essentials to a new chat.

For developers: the same interruption in the API

When calling the API with stream: true, the same failure appears as a Server-Sent Events connection that ends without finish_reason. The HTTP status is 200 — everything was fine when the headers were sent — so checking only the status code does not detect it; under load, 429 and 529 overloaded_error also appear. Three things make it manageable: (1) treat a stream that ended without finish_reason as retryable, not as a complete response; (2) retry 429, 500, and 529 with exponential backoff plus jitter; (3) if a proxy is involved, check its idle timeout and disable response buffering — a proxy that buffers turns a working stream into a long hang. To narrow it down, stream first without a proxy:

# Transmitir directamente, sin proxy por medio, y ver dónde se detiene.
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"cuenta despacio del 1 al 20"}]}'

“Error in message stream”—is it my fault?

Almost never. The message indicates that the connection carrying the response was interrupted before it finished. What you wrote does not cause it. The causes are load on OpenAI’s side, an unstable network, a browser extension or expired session, or a thread that has grown long enough for responses to time out.

What should I do if regenerating does not fix it?

First check status.openai.com — during an incident, nothing local helps. If there is no incident, open a private window on another network: that single test removes extensions, cache, and your usual connection at once. If it works there, add each component back until it breaks again. If it fails everywhere and only in one long conversation, move the essentials to a new chat.

Does it happen with other AI systems too?

The wording is specific to ChatGPT, but any assistant that delivers responses by streaming can be interrupted in the same way. Claude displays a message saying it could not generate the complete response; in a direct API call, it appears as an SSE stream ending without finish_reason, or under load as a 529 overloaded_error.

Why does it happen more often in long conversations?

Each turn resends the entire thread, so a long conversation means a longer generation sustained over a single open connection. The longer it remains open, the more opportunities there are for a proxy timeout, network hop, or upstream issue to break it. Starting a new chat with a summary of what matters usually helps more than any browser setting.