See what a token stream really sends, what happens when the reader is too slow, and how a dropped connection picks up where it left off.
When an assistant types its answer out word by word, there is a small protocol underneath doing the work. This page shows you that protocol: the exact text frames that go down the wire, how long the first word took to arrive, and how evenly the rest followed.
Then it shows the awkward part. The model produces words faster than a slow reader can take them, so something has to hold the difference. The buffer here is deliberately small, and you choose what it does when it fills up: make the model wait, which keeps every word but slows everything down, or throw words away, which stays fast but leaves holes in the answer. You see both, with the cost of each measured.
Last, it kills the connection halfway through and reconnects. The reader tells the server the id of the last word it actually received, and the server carries on from the next one, so the answer arrives complete with nothing repeated.
One honest note: this page shows the protocol and the buffer behaviour, not a live open connection. The server this runs on is a serverless function that cannot hold a stream open, so the frames, the timings and the buffer decisions are produced in memory and printed. Everything you see is real code doing the real thing, just not across a socket.