How do you consume a streamed OpenAI Chat Completions response chunk by chunk?

## Turning it on Streaming is a single request flag: `stream: true`. The HTTP response then uses Server-Sent Events — a long-lived `text/event-stream` connection where the server pushes `data:` lines as tokens are produced. The point is perceived latency: the user sees the first words in a few hundred milliseconds instead of waiting for the whole answer. ## The chunk shape Each event holds a JSON object whose `object` field is `"chat.completion.chunk"`. It has the familiar `id`, `created`, `model` and `choices` fields, but inside `choices[0]` you get `delta` instead of `message`. The typical sequence for one completion is: 1. A first chunk whose delta contains `role: "assistant"` and usually empty content. 2. Many chunks whose delta contains a short `content` string — often a word fragment, not a whole word. 3. A chunk with an empty delta and `finish_reason` set (`"stop"`, `"length"`, `"tool_calls"` or `"content_filter"`). Nothing gives you the assembled text: concatenating deltas in arrival order is your job. Because fragments split mid-word, never parse a partial accumulation as JSON or Markdown until the stream ends. ## Ending the stream On the wire the final line is literally `data: [DONE]`. If you are reading raw SSE — with a plain HTTP client, or proxying to a browser — you must recognise that sentinel, because it is not valid JSON and will break a naive parser. The official SDKs handle it: iterating the returned stream object simply stops. ## Getting usage while streaming A streamed response does not include token counts by default, which surprises people who bolt streaming onto working code and watch their cost telemetry go blank. Send `stream_options: {"include_usage": true}` and the server appends one final chunk with an **empty** `choices` array and a populated `usage` object. That empty array is exactly why loops written as `chunk.choices[0].delta.content` start throwing an index error the day someone enables usage — always check that `choices` is non-empty before indexing. ## Errors mid-stream The hard operational fact: the HTTP status is sent before generation finishes, so a stream that has already returned 200 can still fail. Failures show up as an error payload inside the stream or as an abruptly closed connection, not as a 500 you can catch around the call. Your consumer therefore needs a read timeout between chunks, a way to mark a partial answer as incomplete in the UI, and a retry policy that understands the request is safe to replay (it is stateless) but will regenerate from scratch and bill again. Track whether you ever received a `finish_reason`; its absence at end-of-stream means the answer is truncated regardless of what arrived. ## Buffering through your own backend Most apps do not call OpenAI from the browser — the API key would be exposed. You proxy: the server calls OpenAI with `stream: true`, then re-emits its own SSE or WebSocket to the client. Two things to get right are disabling response buffering in any intervening proxy, which otherwise defeats streaming entirely, and propagating cancellation — if the user navigates away, close the upstream stream so you stop paying for tokens nobody will read. ## When not to stream Streaming buys nothing when no human is watching the tokens appear: batch jobs, evaluation harnesses, and anything that must validate a complete structured payload before acting. In those cases the extra plumbing — partial state, sentinel handling, mid-stream failures — is pure cost.