What event sequence does the Anthropic Messages API emit over SSE when streaming?

## Why stream at all The Messages API can hand back the whole assistant message as one JSON body, or — when you send `"stream": true` — deliver it incrementally as a Server-Sent Events (SSE) stream over the same HTTP request. SSE is a one-way text protocol: the server responds `200` with `content-type: text/event-stream` and then writes frames shaped as an `event:` line, a `data:` line holding JSON, and a blank line, keeping the connection open until it is done. Streaming buys time-to-first-token, so a user sees prose while the model is still generating, and it is the practical shape for long generations, which Anthropic explicitly recommends streaming for rather than waiting on a single buffered response. ## The event sequence **`message_start`** — exactly one, first. Its payload is a `message` object that looks like a normal non-streaming response with `content` set to an empty array: you get the `id`, `model`, `role`, and a `usage` object whose `input_tokens` is already final (along with the cache-related input counters when prompt caching is in play). Output counts are not meaningful yet. **Per content block** — a message may contain several blocks (text, tool use, thinking), and they stream one at a time, in order. Each opens with **`content_block_start`**, which carries an integer `index` and a stub of the block, for example `{"type": "text", "text": ""}` or a `tool_use` block with its `id` and `name` but an empty `input`. Then come one or more **`content_block_delta`** events, each with the same `index` and a `delta` object holding the fragment. The block is closed by **`content_block_stop`** with that index. Nothing about the block is guaranteed complete until its stop event. **`message_delta`** — one event near the end, carrying the top-level fields that were unknowable at `message_start`: `delta.stop_reason`, `delta.stop_sequence`, and a `usage` object with the message's output token count. If you bill, log, or branch on why generation ended, this is where the information lives. **`message_stop`** — the terminator. Its arrival is your only positive signal that the message finished cleanly; a stream that just goes quiet was truncated. **Interleaved anywhere** — `ping` events, which are keepalives with no content and should simply be skipped, and `error` events, which carry an error object such as `{"type": "overloaded_error", "message": "Overloaded"}` and can arrive after content has already been delivered. ## Reading it in practice Most people never hand-parse the frames. The official SDKs expose two levels: a raw iterator over the typed events, and a higher-level streaming helper that accumulates the events into a message for you while still letting you observe text as it arrives. The raw level matters when you are relaying the stream to your own frontend, since you usually re-encode it into your own event protocol rather than forwarding Anthropic's frames verbatim — that keeps your API key off the browser and lets you inject your own error and metadata frames. ## The two rules that catch people *Order is per-block, not global.* You cannot assume one text block; do not concatenate every delta you see into a single string without honouring `index`, or a message that opens a tool-use block mid-answer will corrupt into nonsense. *Forward compatibility is required, not polite.* Anthropic documents that new event types may be added, so a `match`/`switch` that raises on an unknown `type` is a latent production outage. Skip unknown events and unknown delta types; keep the ones you understand. ## What interviewers are really checking The named sequence is the surface question. Underneath, they want to see that you know (a) the stream carries structure, not just characters, so your client is a small state machine rather than a string buffer; (b) `message_stop` is the completeness signal, so a client that renders whatever arrived and calls it done will silently ship truncated answers; and (c) the interesting metadata — stop reason and output usage — arrives at the *end*, which is why you cannot compute the cost of a request from `message_start` alone. A candidate who can sketch the sequence and then say what each event is *for* is well past the recitation answer.