“Streaming interrupted. Waiting for the complete message” — what it means and how to fix it

The 90-second three

Regenerate the response, reload the page (fully quit and reopen the app if you are on mobile), then sign out and back in. A one-off dropped connection is cleared by one of these three, and most cases are one-off. If it stops at the same point every single time, that is a signal the cause is one of the specific ones below rather than a transient drop.

Decide whether it is yours at all

This is the step the other fix lists skip, and it is the one that saves the most time. Open status.openai.com. If an incident is showing, no setting on your machine will change anything and the only fix is to wait. If nothing is showing, the cause is local and the next step isolates it. Doing this before you start changing settings means you never spend twenty minutes clearing caches for an outage.

Isolate the local cause from the outside in

Work through the layers in this order, because each one rules out everything above it: (1) turn off VPN and proxy; (2) open a private window, which removes extensions and cache in a single move; (3) try a different browser or device; (4) switch networks. The layer at which it starts working is the cause. If the error only shows up in long threads, none of the four is the problem — move the key points to a new chat.

For developers: the same cutoff on the API

Calling the API with stream: true, this failure arrives as a Server-Sent Events connection that ends without a finish_reason. The HTTP status is 200 — it was fine when the headers were sent — so status-code checks alone will not catch it, and under load you will also see 429 and 529 overloaded_error. Three things make it survivable: (1) treat a stream that ended with no finish_reason as retryable, not as a completed answer; (2) retry 429, 500 and 529 with exponential backoff plus jitter; (3) if you sit behind a proxy, check its idle timeout and turn response buffering off — a buffering proxy converts a working stream into one long stall. Reproduce it without the proxy first:

# Stream directly, no proxy in the path, and watch where it stops.
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-6","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"count slowly from 1 to 20"}]}'

Is “streaming interrupted, waiting for the complete message” my fault?

Almost never. The message means the connection carrying the answer was cut before the answer finished. What you typed does not cause it. The causes are load on OpenAI's side, an unstable network, a browser extension or stale session, or a thread that has grown long enough to make responses time out.

What if regenerating does not fix it?

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

Does this happen on other AI chats?

The wording is ChatGPT's, but every assistant that streams answers can drop the same way. Claude shows a message about not being able to complete the response; on a direct API call it appears as a Server-Sent Events stream that ends without a finish_reason, or as a 529 overloaded_error under load.

Why does the error appear more often in long conversations?

Each turn re-sends the whole thread, so a long conversation means a longer generation held on one connection. The longer that connection is open, the more chances there are for a proxy timeout, a network handover or an upstream hiccup to break it. Starting a fresh chat with a summary of what matters is usually a bigger improvement than any browser setting.

Am I charged when a stream is interrupted?

On ChatGPT subscriptions there is no per-message charge, so nothing is lost beyond the time. On the API, billing follows the tokens the provider actually produced, so a stream that dies early costs less than a complete one — and on Kunavo a request that fails outright is not billed at all.