A developer notices that when using streaming with extended thinking enabled, the thinking content blocks appear before the text content blocks in the stream. The application needs to display the final answer to the user while optionally showing thinking to developers. What is the correct approach to handle thinking blocks in the stream?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — b is correct because the SSE stream for extended thinking responses includes content_block_start events with a type field that distinguishes 'thinking' blocks from 'text' blocks. The application can route delta events to different handlers — streaming text deltas to the user-facing display while capturing thinking deltas in a debug log — without buffering the entire response.
Full explanation below image
Full Explanation
B is correct because the SSE stream for extended thinking responses includes content_block_start events with a type field that distinguishes 'thinking' blocks from 'text' blocks. The application can route delta events to different handlers — streaming text deltas to the user-facing display while capturing thinking deltas in a debug log — without buffering the entire response. This enables real-time user display while maintaining developer observability. B is wrong because buffering until message_stop defeats the purpose of streaming for the user; it introduces full response latency before any display update. D is wrong because the Anthropic API does support streaming with extended thinking; the stream simply includes additional event types for thinking blocks. A is wrong because thinking block generation cannot be suppressed via system prompt instruction once extended thinking is enabled; the thinking parameter controls thinking at the API level, and the model generates thinking blocks as part of the extended thinking process.