Which Anthropic streaming event carries the final stop_reason and output usage?

## The split: what is known when A streamed message reveals its metadata in two places, and the split follows from causality. **At `message_start`**, the server already knows everything about the *input*: the message `id`, the `model` that will serve it, the role, and `usage.input_tokens` — plus the cache-related input counters when prompt caching is used. What it cannot know is how the generation will end or how long it will run, so the output side is a placeholder, not a prediction. **At `message_delta`**, one event after the final `content_block_stop`, the server patches in exactly the fields that were unknowable at the start: `delta.stop_reason`, `delta.stop_sequence` (populated only when a custom stop sequence triggered), and a `usage` object with the output token count for the message. Then `message_stop` closes the stream. A useful way to hold it: `message_delta` is a diff against the message shell you received at the start. Apply it, add your accumulated content blocks, and you have reconstructed the non-streaming response body exactly. ## Why it matters operationally **Cost accounting.** Output tokens are typically the more expensive side of a call, and you do not have that number until `message_delta`. Any per-request cost metric, budget guard or user-facing usage meter must therefore be recorded at the end of the stream, from that event or from the SDK's assembled final message — never estimated from what you happened to render. **Truncation detection.** The stop reason distinguishes a model that finished its thought from one that hit your `max_tokens` ceiling. Without it, a reply cut off mid-sentence looks like any other reply. Services that silently truncate long answers almost always have this bug: they stream text to the UI and never consume the terminal events. Log the stop reason on every call; a rising share of max-token stops is a signal your ceiling or your prompt needs work. **Control flow.** In an agent loop, the stop reason is what tells you the model wants a tool executed rather than having produced a final answer. Streaming does not change the loop, but it changes when you learn the branch: not while the block is arriving, but after `message_delta`. Kicking off tool execution from a partially streamed block is the corresponding anti-pattern — the arguments are not complete until the block's stop event, and the branch is not confirmed until the message-level delta. **Client shutdown.** A UI that stops reading the moment the visible text looks finished will drop `message_delta` entirely, and with it the usage numbers and the stop reason. Drain the stream to `message_stop` even when you have nothing left to render; the tail is cheap and carries the information you will want in your logs. ## Reading it in code With the raw event iterator you branch on the event type and pull the fields off `message_delta` yourself. With the streaming helper the SDK assembles everything and hands you a final message object whose `stop_reason` and `usage` are already populated — the same object shape a non-streaming call would have returned. That equivalence is the point: streaming should change *when* you learn things, not *what* you can learn. ## Common confusions worth naming *Expecting usage on `message_stop`.* It is a bare terminator; the numbers arrived one event earlier. *Reading output tokens from `message_start`.* The output has not been generated yet, so the value there is not the answer to any question you care about. *Counting tokens client-side instead.* Estimating output length by counting characters you rendered is guesswork and will not match billing; the server's number is authoritative, and it is right there in the stream. *Assuming input tokens change during the stream.* They do not — the input was fixed when the request was sent, which is why that half of the accounting is available immediately.