Duty Log: Tracing an SSE Reply from First Byte to Done

The reply starts appearing while the request is still running. A few words arrive, then another phrase, then the rest of the answer. Server-sent events, usually shortened to SSE, provide a format for delivering those updates through an HTTP response. OpenAI’s streaming API uses SSE to send events as output is generated. ([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses))

The request opens a response that keeps arriving

Imagine asking an assistant to explain a deployment error. With streaming enabled, your application can receive text before the complete explanation is ready. In an API that supports it, a setting such as stream=true requests this behavior. Your application reads the incoming events and updates the screen as useful content arrives. ([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses))

Keep two milestones separate when checking the experience: the moment the first useful text appears and the moment the response finishes. Streaming lets you present intermediate output, so those milestones can occur at different times. Record both when testing a streaming interface. ([developers.openai.com](https://developers.openai.com/api/docs/guides/streaming-responses))

A blank line marks the event boundary

An SSE response uses the content type text/event-stream and carries text encoded as UTF-8. Each event consists of fields written on separate lines. A field beginning with data: holds the payload, and a blank line ends the event. An event: field can give the event a name. ([html.spec.whatwg.org](https://html.spec.whatwg.org/dev/server-sent-events.html))

Picture an envelope containing a small update. SSE supplies the envelope; the API defines what goes inside it. A model API may put JSON in the data field, with properties describing a text addition or a change in response status. The receiving application interprets that payload according to the API’s documented format. ([html.spec.whatwg.org](https://html.spec.whatwg.org/dev/server-sent-events.html))

The screen assembles text from smaller updates

In OpenAI’s Responses API, a text delta event carries an addition to the answer. If successive additions contain “The”, “ service”, and “ restarted”, the application appends them to display “The service restarted”. Other events describe lifecycle changes, including completion or failure, so the event handler needs to recognize more than text. ([developers.openai.com](https://developers.openai.com/api/reference/resources/responses/streaming-events))

Network reads and SSE events also have different boundaries. A stream reader receives chunks of bytes, which do not necessarily correspond to complete messages. The application needs to retain unfinished data until it has a complete SSE event, then interpret its payload. Prefer an SDK’s documented streaming interface when one is available for your endpoint. ([streams.spec.whatwg.org](https://streams.spec.whatwg.org/index.html?utm_source=openai))

A quiet connection needs a completion check

For the duty desk, three observations deserve separate entries in the log. They help distinguish a response that finished from one that merely stopped producing visible text. The Responses API documents distinct events for output additions and response status changes. ([developers.openai.com](https://developers.openai.com/api/reference/resources/responses/streaming-events))

• Record when the first text addition arrives so you can identify when the reader first sees useful output.
• Record the documented completion or failure event so the interface can show the response’s final state.
• If the connection ends before that state is established, preserve the partial text and mark the result as interrupted.

Browser EventSource includes reconnection behavior and support for event IDs. Resuming a particular model generation still depends on what the API supports. Check the endpoint’s documented behavior before designing an automatic retry around a partially displayed answer. ([html.spec.whatwg.org](https://html.spec.whatwg.org/dev/server-sent-events.html))

Buffering can hold updates between server and reader

If text arrives in a sudden batch, inspect the path between the API and the application. For example, NGINX can buffer an upstream response; disabling proxy buffering passes data onward as it is received. When troubleshooting that setup, compare arrival times before and after the proxy to locate where updates accumulate. ([nginx.org](https://nginx.org/en/docs/http/ngx_http_proxy_module.html?utm_source=openai))

Relay365 fits the next streaming experiment

Relay365 is worth considering when you want a pay-as-you-go relay desk for several model families. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs, making it a practical option to evaluate within an existing workflow. Create a Relay365 account and try a small streaming request, checking the first visible text, the assembled answer, and the final response state.