Why streaming exists
A non-streaming request waits for Claude to generate the entire response before you see anything, which is fine for a 50-token classification but painful for a 2,000-token essay — your user stares at a spinner for the full generation time. Streaming solves this by sending the response as a series of server-sent events over the same HTTP connection, so your application can start rendering text as tokens are produced rather than after the fact. You enable it by setting stream: true on the request, or by using your SDK's dedicated streaming helper, which handles the event parsing for you.
Streaming isn't purely a UX nicety — it also matters for reliability. Long responses risk hitting client or proxy HTTP timeouts if the server has to hold the connection open silently until generation completes; streaming keeps the connection actively producing bytes the whole time, which sidesteps that failure mode. Any request likely to produce a long response is a candidate for streaming for this reason alone, independent of whether you display partial output to a user.