anthropic stream ended before message_stop error

• Streaming Messages API calls intermittently return partial text and no stop reason. - The failure rate rises on long outputs and is rare on short ones, which points at a timeout on a long-lived connection. - Your code logs a stream-ended error but never logs an API error, a request id, or the last event type.

Log the last event received. Instrument the stream loop to record the type of every event and print the last one before the close. Expected: you see where the cut happened, usually after contentblockdelta events during a long generation, or right after an error event.

Check for a mid-stream error event. Look for an error event in the stream, for example an overloadederror or an apierror sent after the response started. Success check: if an error event is present, the API did report the failure in-band; surface that error in your code instead of the generic stream-ended message, and retry with exponential backoff.

Test the same request without your proxy in the path. Run the identical streaming request from a direct connection, bypassing any reverse proxy, corporate gateway, or serverless edge layer. Expected: if the direct stream reaches message_stop, an idle timeout or response buffering setting in the middle layer is closing long-lived SSE connections; raise its idle timeout and disable response buffering for the streaming route.

Raise the client timeout and keep retries on. Use the SDK default timeout or a longer one for streaming calls, not a short REST-style timeout, and leave the SDK max retries enabled so transient closes are retried automatically. Success check: a deliberately long generation completes and the stream ends with a messagedelta carrying the stop reason, followed by messagestop.

Handle a cut stream as a failed request. In your own stream consumer, raise or return an error when the connection closes before message_stop, and retry the full request with backoff and jitter rather than appending to the partial text. Success check: a simulated mid-stream disconnect produces one clean retried response, never a half answer presented as complete.

Resolved from the public problem: https://vectle.com/posts/pst_a83N2JMbTF878vW67O4rJw

Problem query: anthropic stream ended before message_stop error

TL;DR: A stream that ends without messagestop was cut, it did not finish: the connection closed mid-response, so no final event is coming and waiting or parsing harder will not help. Log the last event type the client received and check for a mid-stream error event, then test the same request on a direct connection to rule out a proxy or load balancer idle timeout. In production code, treat a missing messagestop as a failed request and retry the whole request with backoff instead of trying to resume the partial stream.