perf(web): streamed assistant text re-renders only its own row#27419

Each assistant delta changed the visible turn items, so ThreadTimeline, ConversationTimeline and the virtual list re-rendered and the list ran three extra layout commits before the streaming row itself updated (about 5 React commits per delta).

The timeline now reads visible items that hold while only streamed assistant text moves (timelineVisibleTurnItemsAtom), and a streaming assistant row reads its own text through assistantMessageTextAtom. Any structural change, including the message finishing, still updates the timeline with the full text. Reasoning items are unchanged. While a message streams, timeline-level readers of its text (minimap preview, find over off-screen rows) see the text from the last structural change; the copy button is already hidden while streaming.

Commits per delta drop from about 5 to 2. The stream render scenario asserts the timeline renders at most 3 times across 30 deltas (32 on main). Checked in the dev app with the Replay provider: streamed text grows and the finished reply renders in full.

Benchmark

Measured with the PandaCode vs T3 Code streaming bench (W1: a 50 KB Markdown reply delivered as 500 whole-text updates over 32 s, production build, headless Chromium on cups, median of 3 runs). Each row adds one layer of this stack:

The bench delivers an update every 64 ms. In the app the default paragraph streaming mode sends at most one every 400 ms, so real streams hit these paths less often, but each update costs what it does here.

Implemented by Claude Opus 5.5 in Claude Code, running in T3 Code.

🤖 Generated with Claude Code