LearnGrokA stream that stops early looks the same to a user in every case, but there are four distinct causes and they have nothing in common. Identify which one you have before changing anything.
1. It hit the output limit
The most common cause and the easiest to confirm: the final chunk carries a finish reason indicating the length limit rather than a natural stop. Log the finish reason of the last chunk; if you are not logging it, start there, because without it you are guessing.
Fix: raise the maximum output tokens, or ask for a shorter answer. Note that a higher limit only helps if the context window has room for it.
2. The connection was dropped
Timeouts and idle-connection limits in the layers between you and the API (proxies, load balancers, serverless platforms, CDNs) will cut a long-running response, and many of them do it silently.
Signs: it always fails at roughly the same elapsed time rather than the same token count. Check every hop's timeout, not just your HTTP client's. Serverless function duration limits are a frequent culprit and are usually shorter than people remember.
3. An error arrived mid-stream
A stream can begin successfully and fail afterwards. When it does, the error comes through inside the stream rather than as an HTTP status, because the status line was already sent as 200. Client code that only checks the response status treats this as a clean, short answer.
Fix: handle error events in the stream explicitly, and never treat "the stream ended" as "the response completed" without checking the finish reason.
4. Your own client stopped reading
Buffering, an unhandled exception in the consumer, or a UI framework that unmounts the component holding the reader will all end a stream from your side. If the same request works with streaming disabled, suspect this before suspecting the API.
Making this diagnosable
Log, for every streamed response: the finish reason, the number of chunks, the elapsed time and the total tokens. Those four numbers separate the four causes above immediately, and none of them can be reconstructed after the fact.
What changes
Timeout behaviour on the platform you deploy to changes more often than the API does. Re-check your hosting provider's limits after any platform migration or runtime upgrade.
