Network Chunks Are Not Complete Streamed Messages

A streamed response arrives before its work finishes

A streaming API lets your application receive output while the server is still producing it. Instead of waiting for one finished response, a chat interface can display text as it becomes available. Server-sent events, usually shortened to SSE, provide a text-based format for delivering those updates over an HTTP connection.

The essential distinction is simple: the network delivers pieces of bytes, while SSE defines complete events. Those pieces do not necessarily arrive at the same boundaries. Reading a stream correctly means rebuilding events before interpreting their contents.

Network reads do not define event boundaries

A single network read might contain half an event, several events, or the end of one event followed by the beginning of another. A successful read therefore does not mean you have received a complete message. Trying to parse every incoming chunk as JSON is a common beginner mistake.

There is another boundary underneath the text: character encoding. SSE uses UTF-8, and a character can occupy multiple bytes. A network chunk may end halfway through one character. Use a streaming text decoder that preserves unfinished characters between reads, rather than decoding each chunk independently.

After decoding, keep unfinished text in a buffer. Read complete lines from that buffer and assemble events according to SSE rules. A blank line ends an event. Line endings may be a line feed, a carriage return, or both together, so a parser must handle those forms, including when they cross chunk boundaries.

Event fields describe messages rather than network pieces

Within an event, the data field carries the payload. Multiple data lines belong to the same event and are joined with newline characters. Only after the event is complete should your application interpret that combined payload, perhaps as JSON. SSE itself does not require JSON.

Other fields have separate purposes. The event field names an event type, the id field supplies an event identifier, and the retry field can advise a reconnection delay. Lines beginning with a colon are comments, often used as heartbeats. A heartbeat can show that a connection is alive without adding any visible text.

Payloads also need interpretation. A model stream may contain text increments, tool-call arguments, usage information, or lifecycle notifications. Not every event belongs in the chat window. Follow the provider's event schema, and distinguish incremental additions from cumulative snapshots to avoid repeating output.

A closed connection does not always mean success

Before processing the body as SSE, check the HTTP status and expected content type. Authentication failures and rate limits may arrive as ordinary error responses rather than event streams. Once streaming begins, later failures may instead appear inside events or as an abrupt disconnection.

Look for the endpoint's documented completion signal. Some APIs use a special marker; others use a named event or a structured field. There is no universal model-completion marker built into SSE. If the connection closes without the expected signal, treat the result as potentially incomplete. Do not promote an unfinished event left in the buffer into a valid message.

Reconnection also requires care. Browser EventSource supports automatic reconnection, but a streamed request made through a general HTTP client does not automatically inherit that behavior. Repeating a model request can generate a new answer and additional charges. Event identifiers support resumption only when the server implements it.

Relay connections still require provider-aware stream handling

BestRelay publishes this guidance as a quality-first API relay that forwards each request to the official model named in it, without substitution. It covers Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok, and more, and works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. An SDK may handle SSE framing, but applications still need to handle event meanings and failures.

BestRelay bills pay-as-you-go using provider-reported token counts, with cache reads and writes priced separately. Network chunks are not token counts. Members also earn referral commission when invited users top up. Create a BestRelay account to try a streamed request.