“ChatGPT message stream error” — causes and solutions

The three actions for the first 90 seconds

Regenerate the response → reload the page (on mobile, fully close and reopen the app) → sign out and sign in again. A one-off drop is resolved by one of these three, and one-off is the normal case. If it instead stops at exactly the same point every time, that signals that one of the specific causes below is active, not a random incident.

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 an incident is in progress, no local adjustment will change anything and waiting is the only option. If nothing is listed, the cause is local and the next step narrows it down. Checking this before changing settings prevents spending twenty minutes clearing cache during an outage.

Isolate the local cause from the outside in

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

For developers: the same failure in the API

When calling the API with stream: true, the same failure arrives 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 catch it; under load, 429 and 529 overloaded_error also appear. Three things make this survivable: (1) treat a stream that ends without finish_reason as retryable, not as a complete response; (2) retry 429, 500, and 529 with exponential backoff plus jitter; (3) if there is a proxy in the path, check its idle timeout and disable response buffering — a buffering proxy turns a working stream into a long hang. To isolate the issue, stream first without a proxy:

# Transmitir direto, sem proxy no caminho, e ver onde para.
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":"conte devagar de 1 a 20"}]}'

Is “message stream error” my fault?

Almost never. The message says that the connection carrying the response was cut off before it finished. What you wrote does not cause this. The causes are load on OpenAI’s side, an unstable network, a browser extension or expired session, or a conversation that became long enough for responses to exceed the timeout.

What if regenerating does not fix it?

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

Does this happen with other AIs too?

The wording is ChatGPT-specific, but any assistant that delivers responses by streaming can fail in the same way. Claude displays a message saying it could not generate the complete response; in a direct API call, this 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 longer generation sustained over one open connection. The longer that connection stays open, the more opportunities a proxy timeout, network change, or upstream hiccup has to break it. Starting a new chat with a summary of what matters usually helps more than any browser adjustment.