Studio: keep long reasoning responsive with bounded pages - #10717

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

@codex review

Confirmed the unbounded mounted trace in studio/frontend/src/components/assistant-ui/reasoning.tsx is still what main does, and the bounded page approach addresses it. Since browser find, native selection, printing and screen-reader traversal now only reach the mounted page, could you say how a user is expected to search a long trace before I review?

@codex review

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 1f52281ca6

@codex review

You have reached your Codex usage limits for security reviews. Please try again later.

@codex review

You have reached your Codex usage limits for security reviews. Please try again later.

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: c17668ec49

Long reasoning opens on a bounded page. At c17668ec4, Earlier no longer shows the latest body after the source range changes. Earlier, Newer, and Latest each render the matching source. Copy retains the full 152,398-character trace, and reload preserves the separate answer. Browser Find stays within the mounted page.

The new browser regression fails before the fix and passes after. 19 focused tests, type checking, the build, frontend CI, and Linux and Windows Studio UI checks pass. The optional Python 3.13 backend check still fails its unchanged idle-stream persistence assertion. Two optional macOS jobs remain queued; no required checks are reported. Local tests used saved or synthetic messages without GPU inference. Final-head review reported no major issues. Final-head security review was unavailable because of a service usage limit.

BEFORE: e726fb1f563948fabde75f35fd745158c210f3e9. AFTER: c17668ec4955672fba39ba60a9e9ef4ebf4f0e27. Same saved conversation, 1440x1000, Microsoft Edge.

Follow-up from re-checking this on studiobench and fuzzing the selector: #10922.

One latent defect, not a live one. pageStart could return an offset equal to the page end, which yields an empty page, and since Earlier sets the next page's end to this start, the chain then stops advancing. It needs maxCharacters at or under BOUNDARY_SEARCH_CHARACTERS, and reasoning.tsx passes no maxCharacters, so the shipped 8,192 default never reaches it. Nobody has hit this. It is reachable through the exported option, so it is worth closing.

Two things this did confirm about the change here. Pagination fires as described: on the studiobench 100K fixture, the largest pane goes from 76,618 mounted characters and 11,978 elements to 8,319 and 24, the whole open-reasoning document from 41,641 elements to 25,255, and the six panes under the trigger are byte-identical between arms. And the module is unusually conservative about platform surface, Range.intersectsNode rather than the non-standard Selection.containsNode, no lookbehind or /u in the fence regex, nothing persisted; Blink, Gecko and WebKit agree exactly on its output.

Worth knowing separately: on that fixture two of the three paginated panes rendered through the oversized-code plain-source fallback rather than the Markdown page, so part of the DOM reduction is Shiki not running at all. That is the labelled fallback working as designed, just more often than the description here implies.

Closing the half of this I said was unanswered.

My earlier note only covered saved traces, because the stock ladder pins every streamed reply at STREAM_TAIL_CHARS = 6,000, of which about 404 characters are reasoning at the 100K rung. The live claim here was therefore unreachable on it, and CONTRIBUTING-perf.md says so itself: a mechanism whose cost scales with reply length reads as a flat floor on this ladder.

--stream-tail-chars 110000 moves the streamed turn onto a reasoning-kind corpus unit and delivers 88,030 reasoning characters in one live reply, 5.4x the trigger, crossed 2.05s into a 13.7s stream, so both scroll_during_generation windows and keystroke sit entirely in the post-threshold region. Chromium, 100K rung, 4 reps, base 27a4ff6a^1 against head 27a4ff6a, with a concurrent base-vs-base null on adjacent pinned cores of the same NUMA node.

Two metrics cleared all three gates, and one of them is the streaming one:

Everything else points the same way and does not clear its own floor, so I am not quoting it as a result: jank_index -54.0% against a 63.1% floor, max_frame_ms -32.6% against 41.6%, time_in_jank_pct -30.6% against 37.1%, stream_jank_index -3.2 against 19.0, stream_time_in_jank_pct -1.6 against 4.1. No metric regressed past its floor in either direction.

The invariants that catch this shape of change held exactly. select_all_copy.count.selected_chars reads 123,092 on both arms and clipboard_chars 122,304 on both, delta 0.0%, so bounding the mount did not truncate the copy. Behavioural parity: 0 invariants broken across 64 action pairs. Visible-region parity reports 2 differences, both reasoning_toggle, both the intended change in what is mounted.

Three things I would not want read as more than they are. The cadence is fast, 8,000 characters per second against field's 329, because at field cadence this reply takes 334s and outlasts the 243s film; that is the same accelerated-replay compromise the description above makes, though this one carries a null control and a floor. It is n=4, one rung, one engine. And reasoning_toggle opens all ten panes in one gesture, which the harness's own guide calls a stress gesture and not a user journey.

So the premise holds on both halves now, saved and live, on the venue this repo trusts.