Streaming

Streaming is an API mode in which Claude emits partial response tokens as they are generated rather than buffering the entire completion before returning it. The transport mechanism is Server-Sent Events (SSE) — a unidirectional HTTP stream where the server pushes newline-delimited data: events to the client. To enable streaming, pass stream: true on the request.

The SSE event sequence follows a predictable structure. Generation opens with a message_start event that carries usage metadata and the message ID. For each content block, you receive a content_block_start event (with the block index and type) followed by one or more content_block_delta events that carry incremental text. Once a block finishes, a content_block_stop event is emitted. A final message_delta carries the stop_reason and updated token counts before message_stop closes the stream.

When extended thinking is active, the thinking block's deltas arrive on their own indexed block before the text block's deltas. Consumers should route by block index rather than assuming a single stream of text.

Practically, streaming enables two major UX improvements. First, time-to-first-token (TTFT) drops dramatically — users see text appear within hundreds of milliseconds instead of waiting for a potentially long completion. Second, applications can display a live spinner or token counter and cancel mid-stream if the response diverges from what was needed.

Cancellation is straightforward: close the HTTP connection. Claude's billing is based on tokens actually generated, so you only pay for tokens that arrived before the connection dropped.

Important constraints to know for the exam: streaming is not available with the Message Batches API. Batches are inherently asynchronous — you submit a batch, poll for completion, and retrieve results. Mixing streaming with batches is architecturally contradictory and the API will reject the combination. For high-throughput async pipelines use batches; for interactive latency-sensitive use cases use streaming synchronous requests.

Questions present scenarios and ask candidates to select the correct API mode. Common patterns:

• "A user-facing chat interface needs to display tokens as they arrive" — correct answer: streaming with SSE.
• "An overnight batch of 5,000 analysis jobs should minimise cost" — correct answer: Message Batches API, which does not support streaming.
• "Parse the following SSE event sequence and identify the stop reason" — tests knowledge of event names (message_start, content_block_delta, message_stop) and the stop_reason field on the message_delta event.