A reply rendered as "ipped." — first two characters gone — while the durable log
held it complete. Nothing was lost; the client discarded it.
The streaming buffer is an accumulation of deltas and is only as good as the
socket. The `assistant:text` event that ends the stream carries the whole message
and arrives right after. Committing the buffer and ignoring that text means a
single dropped frame is permanent, even though a correct copy came in immediately
behind it.
Losing a frame is not exotic: restarting the server mid-turn does it, which is how
this was found — three times tonight, by me.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>