How does streaming change the user experience?
The model begins sending chunks after time to first token, while inference continues. Users can start reading or hearing a response before it is complete. This is especially useful for a realtime AI API, but it exposes unfinished content and complicates moderation or schema validation.
What must the application handle?
Support cancellation, dropped connections, duplicate chunks, finalization, and cleanup after errors. Never let a partial stream trigger an irreversible action. Separate display output from tool arguments, and buffer content that needs structured output validation. A stream can fail after it has started: Anthropic’s streaming API, for example, sends server-sent events that may include ping events and an overloaded_error in the middle of a response (Claude streaming docs, read 9 November 2026), so the client must treat an error after the first token as normal, not exceptional. Measure both first output and total completion inside the latency budget, because fast starts can still end in long stalls.
How do we stop a slow response from hanging an agent?
We never treat a response as safe once the first bytes arrive. In our open-source KRS MCP server, an agent tool for Polish company records, each upstream request gets a 15 second timeout, and the code deliberately leaves that timer armed after the headers arrive so it also bounds the body read that follows (read 9 November 2026). Clearing a timeout when headers arrive leaves a stalled body with no limit at all. We test that path with a fake upstream that sends headers and then goes silent: code that clears the timer early hangs on it forever. A model stream is the same problem stretched out, since every chunk after the first is a body read; the general advice is to watch the gap between the first token and the last as well as the first token itself, as described under time to first token.