When a chat gets long, does reopening it have to get slower too?

When a Conversation accumulated a large amount of messages, activity, and reasoning, reopening it could previously cause a noticeable stall. The first content took time to appear, and getting back to an interactive state took even longer.

Keep the history, remove the repeated work

The known-secret set is now computed once per top-level redaction pass instead of being rebuilt repeatedly along the same processing path.

Historical events for an active Turn are replayed in DOM batches across animation frames rather than pushing a large number of DOM updates onto the main thread at once. Collapsed activity and reasoning details are now built only when expanded, and released again when collapsed.

We also removed a duplicate activity render during conversation switching.

On a real long conversation, seconds became milliseconds

• 93–114 ms to first visible content, down from about 1,632 ms
• 280–286 ms to interactive, down from about 8,190 ms
• 0 ms longest main-thread task, down from about 5,209 ms

The history is still fully preserved. The difference is that reopening a Conversation no longer requires the interface to construct every historical detail before it becomes usable again.

Faster reopening without changing the conversation

Session, Project History, Events, and Transcript hashes were identical before and after restart. Restart smoke tests also passed for Pi + ChatGPT, Codex, and DeepSeek.

A long Conversation can keep growing. Its history should not become a penalty every time you come back to it.

Full test suite: 384/384.