The PartToolRequest case in handleContentPart only calls endTextAndAdvance() and leaves any open reasoning span open while tool-input-start/tool-input-available chunks are emitted; reasoning-end arrives later (on next text or in closeSpans), out of order on the wire. The mirror in handleToolTurnPart already closes both spans correctly — add sw.endReasoning() before sw.endTextAndAdvance() in handler.go:343 to fix.

On iterator error inside `streamToolTurn`, the function writes the full terminal sequence (`error`, `finish-step`, `finish`, `[DONE]`) and returns `finishReasonError`, but the caller `StreamModelWithTools` then unconditionally writes ANOTHER `finish` chunk and ANOTHER `[DONE]` because `len(toolRequests)==0` is true. The result is a duplicated terminal sequence `...finish, [DONE], finish, [DONE]` — an SSE protocol violation reachable on any network blip mid-stream during a tool-calling turn. Eith

On maxTurns exhaustion, the trailing `finish-step` chunk at handler.go:514 has no preceding `start-step`, violating the UI Message Stream protocol's matched-pair requirement. Each turn already emits its own paired `finish-step` via `writeToolTurnEnd`, so this extra one is unpaired. Either omit the trailing `finish-step`, or emit a `start-step` before the post-loop tool outputs to properly wrap them in a step.