“Error in message stream” on ChatGPT — causes and solutions

The three actions for the first 90 seconds

Regenerate the response → reload the page (on mobile, fully quit the app and reopen it) → sign out and sign back in. A one-off interruption is resolved by one of these three actions, and one-off is the normal case. If, on the other hand, it stops at exactly the same point every time, that is a sign that one of the specific causes below is involved, rather than random chance.

First determine whether the problem is on your end

This is the step other troubleshooting lists skip, and the one that saves the most time. Open status.openai.com. If an incident is in progress, no local setting will change anything and waiting is the only option. If nothing is reported, the cause is local and the next step narrows it down. Performing this check before changing settings prevents you from spending twenty minutes clearing caches during an outage.

Isolate the local cause from the outside in

Proceed in this order, with each step ruling out everything before it: (1) turn off VPN and proxy; (2) open a private browsing window — this removes extensions and cache in one step; (3) try another browser or device; (4) change networks. The step at which it starts working identifies the cause. If the error appears only in long conversations, none of the four is responsible: move the essential information into a new conversation.

For developers: the same interruption on the API side

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 will not detect it; under load, 429 and 529 overloaded_error can also occur. Three things make it manageable: (1) treat a stream that ends without finish_reason as something to replay, not as a complete response; (2) retry 429, 500, and 529 with exponential backoff and jitter; (3) behind a proxy, 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:

# Streamer directement, sans proxy sur le chemin, et voir où ça s'arrête.
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":"compte lentement de 1 à 20"}]}'

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

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

What should I do if regenerating is not enough?

First check status.openai.com — during an incident, nothing local helps. If there is no incident, open a private window on another network: this single test removes extensions, cache, and your usual connection all at once. If it works, restore each element one at a time until it breaks again. If it fails everywhere and only in a long conversation, move the essential information into a new one.

Does this happen with other AI systems?

The wording is specific to ChatGPT, but any assistant that streams its responses can break in the same way. Claude displays a message indicating that it could not generate the complete response; in a direct API call, this appears as an SSE stream that ends without finish_reason, or under load as a 529 overloaded_error.

Why does the error return more often in long conversations?

Each turn sends the entire thread again, so a long conversation means longer generation held over a single open connection. The longer that connection remains open, the more opportunities a proxy timeout, network switch, or upstream hiccup has to break it. Starting a fresh conversation with a summary of the essential information generally changes more than any browser setting.