Which order of server-sent events does a streamed Messages response follow?
Why A is the answer
message_start, content blocks, message_delta, message_stop
A stream opens with message_start, then each content block starts, sends deltas and stops. message_delta carries the final details and message_stop closes it. ping events can appear anywhere.
In detail
- A stream opens with message_start.
- Each content block then starts, sends deltas and stops.
- message_delta carries final details, message_stop closes the stream, and ping events can appear anywhere.
- Ignore event types you do not recognize, so new ones do not break you.
Use case
An illustrative scenario, not a real incident.
A chat client renders text as it arrives but ignores the end events. Tracking the event order lets it show the final stop reason and usage once the message ends.
See it in different ways
flowchart LR A["message_start"] --> B["content_block_start"] B --> C["content_block_delta"] C --> C C --> D["content_block_stop"] D -->|"Next block"| B D --> E["message_delta"] E --> F["message_stop"]
sequenceDiagram participant A as API participant C as Your client A-->>C: message_start A-->>C: content_block_start A-->>C: content_block_delta, many times A-->>C: content_block_stop A-->>C: message_delta A-->>C: message_stop
stateDiagram-v2 state "message_start" as s0 state "Content blocks" as s1 state "message_delta" as s2 state "message_stop" as s3 [*] --> s0 s0 --> s1 s1 --> s2 s2 --> s3 s3 --> [*]
Key point: A stream runs from message_start to message_stop, with blocks in between.
Why the other options are wrong
- B. message_start, message_stop, then content blocks
- message_stop ends the stream, so content cannot follow it.
- C. content_block_start, message_start, message_stop
- message_start always comes before any content block.
- D. message_delta, content blocks, message_start
- message_delta comes near the end, not the start.