When a streaming call misbehaves, what you have is a wall of event and data lines, and the three things you want to know are all scattered across it: what the model actually said, why it stopped, and what it used. The text arrives in fragments, tool arguments arrive as partial JSON that only parses once the last piece lands, and the usage is split between the first event and the last. This puts all of it back together. Both the common stream shapes are handled, because in practice people paste both, and events that fail to parse are reported rather than quietly skipped.
Features
Text reassembled from its deltas, in order
Tool arguments rebuilt from partial JSON and pretty-printed
Stop reason, model and usage pulled out
Handles both the block-delta and choices/delta shapes
Repeated data lines joined the way the spec requires
Keep-alive comments ignored rather than counted as events
Error events surfaced instead of skipped
Every event expandable, with a count by name
How to use the SSE Stream Viewer
Paste the raw stream
Read the reassembled text
Check the stop reason and the usage
Expand individual events if something is still unexplained
Example
Input
delta: {"type":"text_delta","text":"Order 4471 "}
Output
Order 4471 shipped on 30 August.
Fragments across six events, reassembled in order.
Common errors & troubleshooting
No text comes out. — The stream may have ended before any content — check the events list and the stop reason. A refusal or an error event produces a valid stream with nothing in it.
Tool arguments are truncated. — They arrive as partial JSON across several events. If the stream was cut short the JSON never closes, and the raw fragment is shown instead of a parse.
Some events do not parse. — Usually a stream truncated mid-event when it was copied. Those are reported with their index rather than dropped.
The usage numbers look incomplete. — They are split across the stream — input tokens arrive at the start, output tokens at the end. A stream missing its final events is missing half of them.
Frequently asked questions
What is server-sent events?
A simple streaming format: lines of field and value, events separated by blank lines. It is what streaming API responses use, which is why a failed streaming call leaves you holding a wall of them.
Which stream shapes are supported?
The block-delta shape, where text arrives as typed deltas inside content blocks, and the choices/delta shape. Both are recognised automatically, since people paste whichever their client logged.
Why are tool arguments in pieces?
They stream as partial JSON so the client can begin rendering before the call is complete. That means the fragments only parse once the last one arrives, which is why a truncated stream leaves invalid JSON.
Can I see what it cost?
The usage block is extracted when it is present, including cache reads. It tells you what the call used; the cost tools take it from there.
Is the stream uploaded anywhere?
No. Streams contain the full response and often the prompt that produced it, and all the parsing happens in the browser.