Streaming Event Types Reference

message_start, always. It arrives before any content block exists.

message_stop, always - it's a pure signal event with no payload of its own.

Input tokens are in message_start.message.usage.input_tokens. Output tokens finalize in message_delta.usage.output_tokens.

Check content_block.type on the content_block_start event for that block's index - it's "text", "tool_use", or "thinking".

event.delta.partial_json on content_block_delta events where event.delta.type == "input_json_delta" - accumulate these before parsing as JSON.

No, it's a keep-alive with no payload. Safe to ignore in a type-based dispatch (it just won't match any of your handled cases).

Why the model stopped generating: "end_turn" (natural completion), "max_tokens" (hit the token cap), "tool_use" (paused to call a tool), or "stop_sequence" (matched a custom stop string).

Yes - for example a thinking block followed by a text block, or a text block followed by one or more tool_use blocks, each opened and closed independently by index.

It streams a cryptographic signature associated with an extended-thinking block, used to verify the thinking content wasn't tampered with when passed back in a later turn.

It means the stream ended abnormally mid-generation. Treat it the same as a dropped connection: whatever content arrived before it is incomplete, and the request should typically be retried.

content_block_delta carries incremental content inside one block (text, JSON, or thinking fragments). message_delta carries message-level metadata (stop_reason, final usage) that's only known once generation is wrapping up.

message_start.message.model - it echoes back the model you requested (useful if your code allows a model alias to resolve to a specific dated snapshot).