What this is

Bottleneck 3 from the heavy-thread profiling in #9016: deleting a message from a long chat. It cost 98ms at 25K characters of thread content and 472ms at 300K, growing 4.8x across that range, of which 503ms of the 505ms measured there was script and 1.9ms was style.

The attribution was wrong, and here is the profile

The cost was attributed to the export / rebuild / import round trip in delete-thread-message.ts: export the thread, rebuild it without the message, import it back. That is not where the time goes.

Sampled with the CDP profiler on Chromium at 300K characters (220 messages, 43,422 DOM nodes), inclusive time for one delete of 498ms wall:

deleteThreadMessage                    1.8 ms
syncExportedRepositoryToBackend        1.3 ms
exportedItemToRecord                   0.9 ms

performSyncWorkOnRoot                414.1 ms
  renderRootSync                     299.5 ms
  commitRoot                         114.5 ms
  flushPassiveEffects                 83.4 ms

The whole round trip is under 2ms. The rest is one synchronous React render, in a microtask after the click handler returns, and it is that big because deleting one message re-rendered every remaining message in the thread. Two things caused that, both in thread.tsx.

1. The components map defeats assistant-ui's bail-out

ThreadPrimitive.Messages rebuilds its whole element array whenever the message COUNT changes, so every message's wrapper re-renders on a delete. assistant-ui absorbs that in RenderChildrenWithAccessor: when the render prop returns an element with no props, the same element object is handed back on every render, and React skips reconciling that subtree.

The components={{ UserMessage, EditComposer, AssistantMessage }} form never reaches it. What the render prop returns there is <ThreadMessageComponent components={...} />, whose props object is freshly allocated every render, so the memo can never hit and the whole message body, action bar and tooltip tree is reconciled again for all 219 remaining messages.

This PR renders through the children form and returns one shared propless element. The wrapper still re-renders; what is under it does not. Sharing the element rather than building a fresh propless one also makes the bail-out React's own (current.memoizedProps === pendingProps), so it does not depend on a library detail staying put.

The role and edit-state selectors are exactly the ones assistant-ui's ThreadMessageComponent uses, and threadMessageKind reproduces its getComponent fallback chain for the three components this thread supplies, across all six role x editing combinations. An editing message of any role goes to EditComposer; a system message that is not being edited renders nothing, as it always has.

2. useOwnsResearchMessage re-rendered every action bar, and exported per message

const messages = useAuiState(({ thread }) => thread.messages);
...
return aui.thread().export().messages.some(...)

Selecting the array subscribed every user message's action bar to every thread change, so a delete re-rendered all of them along with their copy, edit, fork and delete controls and their tooltips, whether or not the answer had moved. Behind that, each one exported the whole repository, which is quadratic in thread length and is paid on every token of a generation as well.

It now selects the answer, so nothing re-renders unless the answer changes, and the export is shared across the messages at one revision. The export itself stays: the question is about the whole repository, since a research reply can sit on a branch the view is not showing, and it cannot be read off the visible message list. What is removed is the per-message factor, not the export.

Measured

Harness is tests/studio/playwright_heavy_thread.py from #9016, unchanged, driven against this branch and against its merge base. Paired and interleaved (base, fix, base, fix, ...), because this host's load drifts over tens of minutes and two back-to-back blocks would charge that drift to the change. Every cell is itself the median of 3 repetitions; the round-level number is the median across rounds. Ratios are the headline, absolute milliseconds are context: this is a loaded shared host and the harness runs against a vite dev server, so React is unminified and unbundled.

Chromium, 3 interleaved rounds:

Growth across the range: 4.80x before, 2.45x after.

WebKit, 2 interleaved rounds:

Growth: 7.68x before, 1.88x after.

Firefox, 1 round:

Growth: 6.47x before, 1.81x after.

Two things to read these against. The harness clocks this action across a double rAF, so roughly 33ms of every number above is the vsync floor rather than work; subtracting it, the Chromium 300K cell goes from about 439ms to about 30ms. And one base cell (Chromium, 25K, round 3) timed out on page load and is excluded; its column is the median of the other two rounds.

Nothing else in the harness moved: keystroke, scroll and jump are flat, and menu and reopen are unchanged within run-to-run noise. Those two are separate bottlenecks and are not touched here.

Same output, not just faster: DOM node counts are identical at every size (4,048 / 15,887 / 43,422 before and after), message counts before and after the delete are identical, and both trees report zero console warnings and zero stray API requests.

Tests

Six new tests over the two extracted modules, plus four source pins, all under npm test.

tests/thread-message-slot.test.ts covers the component choice across all six role x editing combinations, and the two properties the bail-out needs: the render prop returns the same element object every time, and that element carries no props.

tests/research-reply-owners.test.ts covers what the shared answer contains, that a rootless reply names no owner, that one export serves every message at a revision, and that a new revision is exported again and sees the change.

tests/thread-delete-render-budget.test.ts pins the three seams that are silently load-bearing, following the existing research-render-budget.test.ts idiom. Undo any one of them and the thread still renders correctly, the unit tests above still pass, and the delete goes back to being linear in thread length: the render-prop form rather than the map, the render prop being hoisted to module scope, and the revision key being the array the store hands out rather than a copy of it.

Each of the 13 tests was run against a deliberately broken tree and shown to fail. Per test, the break it catches:

tests/studio/test_deep_research_frontend_contract.py pinned the exact expression the ownership question used to be written as. Repointed at the question and its scope, not at the expression that used to compute it.

Verification

From studio/frontend: npm test 2949 passed 0 failed, npm run typecheck clean, npm run build clean, biome and eslint on the changed files produce byte-identical diagnostics to the merge base for thread.tsx and nothing at all for the new files.

pytest tests/studio is 3900 passed, 1 failed. The one failure is test_multi_chat_prompt_queue_contract.py::test_composer_only_queues_behind_the_current_chat, which fails identically on the merge base and is fixed by #9026.

Not done here, deliberately

MessagePrimitive.Parts in the same file is passed an inline components literal whose tools object is reallocated per render, and assistant-ui memoizes each part on that object's identity, so that memo can never hit either. It is the same mistake one level down. It does not affect a delete any more, because the message subtree no longer re-renders, so it belongs with the menu and reopen work rather than here.