Repository navigation
perf(client-runtime): context-window updates stop re-sorting a thread's history - #231
Merged
tusharbhardwaj-bk merged 1 commit intoSep 27, 2026
Merged
Conversation
…'s history Each context-window.updated activity (about 20% of a busy thread's activities) took the reducer's slow path: filter every activity, append, sort the whole array with the Effect comparator, and rebuild the id index. Replaying 1,000 events onto a long thread paid that sort for each update. An in-order update (unseen id, sorts at/after the tail of an indexed array) now drops the rows it supersedes in one linear pass and appends, which is the same result without the sort. Replay of 1,000 events onto a 5,542-activity thread: ~355 ms -> ~50 ms. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
github-actions
Bot
added
vouch:trusted
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The client applies each thread event with
applyThreadDetailEvent(packages/client-runtime/src/state/threadReducer.ts). Plain activities already have an in-order fast path.context-window.updatedactivities didn't: every one took the slow path, whichOn the busiest prod thread 1,673 of 8,340 activities (20%) are context-window updates. So replaying a long thread (a resume, or a kept-alive running thread catching up after a wake) paid a full sort for every fifth event. Found by the client-sync analysis subagent.
Fix
A marked block ahead of the slow path handles an in-order context-window update: the array is indexed (so it's known sorted), the id is unseen, and the new row sorts at or after the tail. It drops the same-turn resolvable rows the update supersedes in one linear pass, updates the id index in place, and appends.
That's exactly the slow path's result: removing rows from a sorted array keeps it sorted, and the new row belongs at the end. Out-of-order, redelivered or unindexed cases still take the slow path unchanged.
This is upstream code, so it's a good upstreaming candidate.
Evidence
Micro-benchmark: 1,000 events (25% context-window updates) replayed onto a 5,542-activity thread, 5 runs:
Tests:
threadReducer.contextWindow.expbkt3.test.ts: 3 seeded random streams of 600 activities (tool rows, context-window rows, malformed context-window rows, 40 per turn).threadReducer.test.ts: all pass (58 total).vp run typecheckinpackages/client-runtimeis clean, and the fork-marker check passes.Reaches users: browser users on the next bkmain deploy; desktop users with the next desktop build.
Model/harness: Claude Opus 5.5 via Claude Code in T3 Code.
🤖 Generated with Claude Code