When streaming deepseek-reasoner, how do reasoning_content and content deltas arrive?

## The chunk shape Streaming a `deepseek-reasoner` completion gives you the ordinary OpenAI-compatible server-sent-event stream — a sequence of chunk objects, each with `choices[0].delta` — with one extension. The delta may carry `reasoning_content` instead of, or as well as, `content`: - Early chunks populate `delta.reasoning_content` with fragments of the chain of thought while `content` is empty or null. - Later chunks populate `delta.content` with the answer. - The stream terminates the usual way, with a final chunk carrying a `finish_reason`. So the naive accumulator — append `delta.content` to one string — still produces the correct final answer, which is why porting a streaming client from `deepseek-chat` does not crash. It just shows nothing at all for however long the model thinks. ## Two buffers and a transition The minimal correct consumer keeps two accumulators and watches for the switch: - Append any `delta.reasoning_content` to a thinking buffer. - Append any `delta.content` to an answer buffer. - The first non-empty `content` delta marks the phase change: thinking is done, the answer has begun. That transition is the useful event. Interfaces use it to collapse a live "thinking" pane and hand over to the answer pane; pipelines use it to start incremental parsing of the answer without accidentally feeding reasoning text into the parser. Do not detect the transition by looking for markers in the text — the field split is the contract, and the prose is not guaranteed to signal anything. ## Latency shape is the real story Streaming is usually adopted to improve perceived latency, and on a reasoning model the naive port defeats it. Time to first byte is unchanged and fast, but time to the first token the user sees is the entire thinking phase, which on hard problems can run for many seconds. Users interpret a frozen pane as a hang and retry, doubling your cost for the same answer. The options are all product decisions: - **Render the thinking** live, usually in a de-emphasised or collapsed panel. Honest and informative; requires you to be comfortable showing the trace. - **Render a progress indicator driven by the stream**, so the UI proves work is happening without displaying the trace itself. The arrival of reasoning deltas is a genuine liveness signal — better than a spinner on a timer. - **Accept the wait** and set expectations in copy, which is reasonable for a background or batch flow but poor for chat. The wrong option is a client-side timeout tuned for a non-reasoning model. Reasoning responses legitimately take much longer end-to-end, and a timeout inherited from the chat path will abandon requests that were about to succeed — after you have already paid for the thinking. ## Usage and errors mid-stream Token counts do not arrive in the content chunks. To get the totals on a streamed call, request them with `stream_options` set to include usage, in which case a final chunk carries the `usage` object; otherwise count client-side or fall back to non-streamed calls for the paths where you need exact accounting. Either way, do not infer cost from what you rendered — the thinking you may have discarded is still billed. Also handle the truncation case explicitly on the streamed path. If generation hits the output cap during thinking, the stream can end with a `finish_reason` of `length` and an answer buffer that is empty or clipped. A streaming consumer that renders whatever it accumulated and never inspects the final chunk will silently present half an answer as a whole one. ## Cancellation Because the thinking phase can be long and is billed, cancellation policy matters more than on a chat model. Closing the connection when a user navigates away is worth wiring up, and the transition event gives you a natural point to decide whether a request that has not started answering yet is still wanted. ## Summary of the contract Separate keys in the delta, thinking first and answer second, no marker parsing, transition detected on the first content delta, usage only at the end if you ask for it, and a latency profile that requires a deliberate UI decision rather than a straight port of the chat client.