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

The three steps for the first 90 seconds

Regenerate the response → reload the page (in the app, fully quit and restart it) → sign out and sign back in. A stream that drops once is resolved by one of these three steps, and a one-off occurrence is normal. If it breaks at exactly the same point every time, however, that indicates that one of the specific causes below is present and that it is not random.

First determine whether the problem is on your end at all

This is the step the other guides skip, and the one that saves the most time. Open status.openai.com. If there is an ongoing incident, no local setting will help and waiting is the only solution. If nothing is listed, the cause is on your end, and the next step narrows it down. Checking this before changing things prevents you from spending twenty minutes clearing the cache during an outage.

Narrow down the local cause from the outside in

Proceed in this order, because each stage rules out everything above it: (1) disable VPN and proxy; (2) open a private window — this removes extensions and cache in one go; (3) use another browser or device; (4) switch networks. The stage at which it starts working again is the cause. If the error occurs only in long chats, none of the four is responsible — carry the key points into a new chat instead.

For developers: the same interruption at the API

With a request using stream: true, the same issue 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 a status-code-only check does not detect the interruption; under load, 429 and 529 overloaded_error may also occur. Three things make this survivable: (1) treat a stream that ends without finish_reason as retryable, not as a completed response; (2) retry 429, 500, and 529 with exponential backoff plus jitter; (3) behind a proxy, check its idle timeout and disable response buffering — a buffering proxy turns a working stream into a long hang. To narrow it down, stream without a proxy first:

# Direkt streamen, kein Proxy dazwischen, und beobachten, wo es abbricht.
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":"Zähle langsam von 1 bis 20"}]}'

Is “Error in message stream” my fault?

Practically never. The message means that the connection carrying the response was interrupted before the response was complete. Your input did not cause it. Possible causes include load on OpenAI’s side, an unstable connection, a browser extension or expired session, or a chat that has become so long that responses run into a timeout.

What should I do if regenerating does not help?

First check status.openai.com — during an incident, nothing local will help. If there is no incident, open the page in a private window over another network: this single test removes extensions, cache, and your usual connection at the same time. If it works there, re-enable everything one by one until it breaks again. If it breaks everywhere and only in one long chat, carry the key points into a new chat.

Does this also happen with other AI chats?

The wording comes from ChatGPT, but any assistant that streams responses can break in the same way. Claude displays a message saying that the response could not be generated completely; with a direct API call, it appears as an SSE stream that ends without finish_reason, or under load as 529 overloaded_error.

Why does this happen more often in long conversations?

Every turn sends the entire history again, so a long conversation means a longer generation over a single open connection. The longer that connection remains open, the more opportunities a proxy timeout, network change, or upstream interruption has to break it. A fresh chat with a summary of the essentials usually helps more than any browser setting.