Streaming Response Inspector
A captured stream is thousands of one-line JSON frames. This reassembles them into the message they describe — the text, the tool calls with their arguments joined back together, the usage totals — and points at where it went wrong when it did.
Output appears here as you type.
Runs entirely in your browser. Nothing you paste here is uploaded or stored.
Questions
Is what I paste sent anywhere?
No — and it is worth being concrete about why that matters here. A prompt, a captured response and a tool definition all contain the things people are most careful with: system instructions, customer data, internal endpoints. Every tool on this page is a pure function running in your tab, on a page whose Content-Security-Policy sets connect-src to ‘none’, so the browser will not let it open a network connection at all.
Why not just read the stream?
Because a normal response is thousands of frames, each a fragment of one token, and the interesting parts are spread across all of them. Tool call arguments in particular arrive as a stream of partial JSON in input_json_delta frames — a single argument object can be split across a hundred events, and you cannot tell whether it was complete without joining them.
What does "arguments are not valid JSON" mean?
That a tool call was cut off mid-stream. Arguments arrive as fragments that only form valid JSON once the last one lands, so a partial result means the response ended before the call finished — usually hitting max_tokens, or a dropped connection. It is the most common streaming bug and it is invisible unless you reassemble the fragments.
It says TRUNCATED but my code worked.
Then the capture is incomplete rather than the response. A stream is complete when a message_stop event arrives; copying from a terminal or a devtools pane often loses the tail. It also flags genuinely dropped connections, which is the case worth knowing about.