# Main versus the performance stack, with and without PR 11169

Measured September 10, 2026. The four-PR stack reduces total synchronous client update time by **32.0%** in the fixed streaming benchmark mix. Adding PR 11169 makes that **33.2%** relative to main. Its incremental streaming difference is inconsistent across rounds; its clear benefit is **29.3% lower cached thread-switch latency**, with no sampled blank frames.

## Revisions

- Main: [57aee3e19f](https://github.com/pingdotgg/t3code/commit/57aee3e19f1910f3323f06384bb2a1d02b79e369). Fetched main was also the exact stack base.
- Four-PR tip: [f378a49dcc](https://github.com/pingdotgg/t3code/commit/f378a49dcc0df271e71369828826a146f9aa3c65), comprising [#11181](https://github.com/pingdotgg/t3code/pull/11181), [#11193](https://github.com/pingdotgg/t3code/pull/11193), [#11196](https://github.com/pingdotgg/t3code/pull/11196), and [#11198](https://github.com/pingdotgg/t3code/pull/11198).
- Five-PR tip: [beb61e4d00](https://github.com/pingdotgg/t3code/commit/beb61e4d00e033915754299d144c8c313df4ad85), adding [#11169](https://github.com/pingdotgg/t3code/pull/11169). All 12 original commits were rebased onto the four-PR tip. Two compatibility commits corrected optional callback props and completed test fixtures for current types.

## Streaming results

Milliseconds; median of six run medians. p95 is the median of six per-run p95s.

| Workload | Main median / p95 | Four PRs median / p95 | Five PRs median / p95 |
| --- | ---: | ---: | ---: |
| Prose after completed code blocks | 18.575 / 31.200 | 14.700 / 26.250 | 14.800 / 26.900 |
| Growing code block | 174.425 / 230.350 | 114.775 / 141.900 | 111.775 / 141.750 |

Summed synchronous update durations for the same 960 measured updates per variant:

| Main | Four PRs | Five PRs |
| ---: | ---: | ---: |
| 58,074.1 ms | 39,472.0 ms | 38,810.3 ms |
| Baseline | 32.0% less | 33.2% less |

The four-PR stack improves both workloads in all six paired rounds. Adding PR 11169 improves the prose median in only three of six pairs and growing-code median in four of six. Its 1.7% reduction in the summed mix is not evidence of a reliable additional streaming improvement.

These totals depend on the workload mix. They measure elapsed synchronous client update work, not instrumented CPU time, provider throughput, network latency, or overall application speed. Growing-code updates remain expensive on this runner.

## Cached thread switching

Two synthetic threads with 400 messages / 200 turns each, opened through the normal app. This does not imply all messages are mounted or fetched. Each build had six counterbalanced rounds, warming both destinations before eight measured alternating switches per round.

| Metric | Main | Four PRs | Five PRs |
| --- | ---: | ---: | ---: |
| Destination ready: median of run medians | 252.625 ms | 252.475 ms | 178.500 ms |
| Destination ready: pooled p95 | 290.4 ms | 278.2 ms | 254.2 ms |
| Switches with a sampled blank frame | 48 / 48 | 48 / 48 | 0 / 48 |
| Total sampled blank frames | 374 | 380 | 0 |
| Timeouts / wrong final destinations | 0 | 0 | 0 |

Ready requires the requested route and its unique final-message marker to be visible for two consecutive animation frames; timing uses the first of those frames. The sampler checks viewport intersection and effective visibility, including opacity. Clicks activate the real sidebar controls.

Separate light- and dark-theme stress checks issued 21 alternating clicks at a requested 50 ms cadence without awaiting destination readiness. Both ended on the requested thread with zero sampled blank frames. This is a correctness check, not another latency benchmark. Browser main-thread work can delay the requested click cadence.

Separate recordings preserve Chrome screenshot timestamps when assembling the video. Visual inspection confirms the four-PR stack clears the conversation pane during switches and the five-PR stack keeps content visible. Recordings were not running during timing trials.

## Controls and limits

Production builds, identical temporary probe source, identical isolated server/database, one authenticated Chrome 152 browser and origin, 1440×1000 viewport, Linux x86_64 AMD EPYC-Genoa runner. No CPU throttling. Build order rotates and reverses across six rounds. No concurrent builds, tests or recordings during timing trials.

Streaming updates use the existing client thread atom with immutable data and flushSync, one chunk per animation frame. Completed-code workload: 12 closed TypeScript fences with 30 lines each, 20 warmup and 120 measured prose updates per round. Growing-code workload: 200 initial TypeScript lines, 10 warmup and 40 measured appended lines per round. Initial load and final stream completion are excluded from synchronous update samples. Raw samples are retained; medians are computed from those samples, not the probe's upper-middle shortcut.

Navigation measurements concern warmed, local web navigation. Cold snapshots, remote/tunnel networks, Electron-specific keybindings, mobile, and shipping-device timings were not measured in this comparison. No claim is made about those paths. Temporary probes and evidence were not committed.

## Validation

Three focused timeline/scroll test files passed (192 tests) after rebase. After compatibility fixes, both affected test files passed (184 tests); the final fixture-only correction was followed by another passing 137-test ChatView logic run. Final web typecheck and production build passed. All 144 measured switches completed correctly, plus rapid navigation checks in both themes.

Original PR 11169 implementation: cursor-grok-4.6-high-fast / Cursor. Rebase, compatibility fixes and this comparison: GPT-6 / Codex with agent-browser.