Streaming & Websocket Transport vs. Token Cost

Streaming Delivers Tokens Incrementally

Rather than waiting for the full response to complete before returning anything, **Streaming uses a persistent event stream -- typically server-sent events (SSE)** -- to deliver tokens to the client incrementally as they're generated. This lets an application start rendering or processing output before generation finishes, improving perceived latency (time-to-first-token).

Websockets for Realtime/Bidirectional Cases

Some realtime or bidirectional integrations (for example, voice or live-conversation interfaces) use websockets instead of a one-directional SSE stream, since websockets support two-way communication over a single persistent connection.

Transport Is Not a Cost Lever

The critical distinction: Streaming and websocket choices are transport/delivery concerns -- they change *how* and *when* tokens arrive at the client, not *how many* tokens are generated or billed. A streamed response and a non-streamed response for the same request generate and bill the same number of output tokens; Streaming only changes the delivery pattern.

Common exam traps

• Assuming Streaming reduces token cost or the number of tokens generated -- it changes delivery timing, not billing.
• Confusing Streaming (incremental delivery of a single response) with websockets (a bidirectional connection), or assuming every Claude integration requires websockets -- most Streaming use cases only need SSE.