Four merged PRs moved the chat streaming render path, and each built a throwaway harness to prove it:

Nothing was left behind that would notice the next regression, and each measurement had to rediscover the same methodology. #8845 needed four attempts before its numbers meant anything: a real model gave the two sides different essays, generating the stream in-page competed for the throttled CPU budget, a CSP silently blocked the helper server, and a wall-clock quiet window declared a reply finished in the middle of a freeze.

This keeps the harness.

What it runs

smoke-stream-pacing.html mounts the real MarkdownText inside a real assistant-ui local runtime, in the same shape as the existing smoke-research.html and smoke-autoscroll.html: a vite entry, no backend, no auth, no GPU, no model. A local runtime rather than a bare component because MarkdownText reads its part from assistant-ui context and its BlockComponent reads useAuiState, and because assistant-ui's own update scheduling is where #7892's starvation lived.

tests/studio/playwright_stream_pacing.py drives it under CPU throttling and reports longest stall, long-task total and count, frames over 33 ms, and time to fully painted.

Three methodology points are carried over deliberately, each from a way a measurement went wrong before:

• The reply is a fixed string built by repetition. The renderer's cost is superlinear in length, so comparing two different essays says nothing.
• "Settled" is counted in frames without growth, not in wall-clock time. A freeze blocks the frame loop too, so a frame counter cannot tick through one, which is exactly what a 1.5s quiet window failed to do.
• The finish verdict is computed in the page, not by polling from the driver. Every round trip is itself slowed by the throttling.

Choosing the budgets

A budget picked by feel is not a gate. Two merged fixes were reverted in this harness and measured on two different machines, and they move the two numbers in opposite directions:

Reverting #8750 (incremental Markdown parsing) blows up the long-task total and leaves the longest stall alone. Reverting #7892 (the Streamdown animated configuration that keeps block updates out of an interruptible transition) does the exact opposite: the stall goes 4 to 5x while the long-task total stays inside the clean range.

So both budgets are load-bearing, and a single headline metric would have missed one of these two outright. Every mutated run exits 1 on the budget you would expect and every clean run exits 0, over sixteen clean runs, six with #8750 reverted and five with #7892 reverted.

Machine spread, and why this does not gate yet

Clean long-task readings are 5,029 and 5,901ms on one machine and 6,687 to 8,003ms over five runs on another. So the number varies around 60% across boxes even though a single box repeats to within around 15%, and the headroom over the 10,000ms budget is 1.7x on the first machine but only 1.25x on the second.

The budget is deliberately not raised to buy that headroom back, because the same two machines read the #8750 revert as 13,059ms and 74,353ms. A budget loose enough to be comfortable on the slower box stops catching that regression on the faster one. That tension is the whole reason the step keeps continue-on-error: true: tighten it from observed runner numbers, not from any one machine.

The longest-stall budget needs no such hedging. 2,500ms sits at 2.0x above the worst clean run and 2.0x below the mildest #7892-reverted run, and the stall metric repeats to within 4% on a single box.

What stops it reading a false pass

A harness that cannot fail is worse than nothing, so every number the budgets rest on is asserted to have measured something, and every number is scoped to the stream rather than to the page:

• at least 90% of the characters sent were painted, and the arrival count matches the rate this claims to feed. Without these, a page that rendered nothing scores a perfect zero on every budget.
• the reply is still there at the end. paintedChars is a high-water mark and only ever climbs, so a completion render that truncated the bubble would leave the peak behind and pass the floor on a DOM that no longer held the reply. The length present at settlement is recorded separately and checked against the same floor.
• long tasks were actually observed, and the engine actually supports the entry type. observe({type: "longtask"}) is specified to abort silently on an engine that lacks the type rather than throw, so a try/catch around it never fires: longtask is Chromium-only, and under firefox or webkit the long-task total stayed at 0 and sailed under the budget. Support is detected with PerformanceObserver.supportedEntryTypes, recorded, and failed on.
• CPU throttling was actually applied. Unthrottled, the renderer keeps up with any rate this can feed and every budget passes on any tree.
• a stall that never ends is still a stall. The longest stall used to be written only when a later paint closed it, so a freeze running to the end of the stream went unrecorded while its missing tail hid inside the 90% floor. The stall in progress is measured instead, capped at the moment the stream ended. The cap matters in both directions: a freeze spanning that moment blocks the frame loop across it, so the first frame afterwards already sees an ended stream and the whole interval would otherwise be skipped, while measuring past it would count the quiet frames the settle check itself needs and report a stall on every healthy run. That rule lives in smoke-stream-pacing-stall.ts with its own tests, two of which fail if the previous rule is put back.

Long tasks and slow frames are counted only from the moment the stream is asked for, so page load and module evaluation are not budgeted as render cost. That was measured at one entry of about 140ms, roughly 2.6% of a clean total. A long task carries the start time of its whole task, so the message append is handed to a later task, or runtime startup and the first publish would sort before the window and be dropped as page load.

A broken page fails fast rather than hanging: with the fixture deliberately crashed on load the driver exits 1 in 65s on the readiness wait, well before the 300s settle deadline.

Chromium only, and deliberately

Both of the things that make this a measurement are Chromium-only: Emulation.setCPUThrottlingRate is reached over CDP, which Playwright exposes for Chromium alone, and longtask entries exist in no other engine (the Gecko bug is open, WebKit has never shipped them). Verified against all three engines: the page renders fine under firefox and webkit, new_cdp_session raises CDP session is only available in Chromium, and supportedEntryTypes excludes longtask without observe() throwing. Hence the explicit support check rather than a catch.

This step will not execute yet

The step is added after Browser smoke for ANSI tool output, which is currently failing on main and does not carry continue-on-error. A failing step without it skips every step after it in the job, so this one reports as skipped rather than running, which is what happened on a replicated CI run of this branch. That is being handled separately and is not fixed here, but it is worth stating plainly: until it is resolved, a green Frontend CI is not evidence that this harness ran.

It is also why the budgets are still calibrated from developer machines rather than from runner numbers.

Limitation

createStreamPublishGate from #8845 lives in the Studio chat adapter, not in this render path, so this harness does not exercise it. What it covers is everything downstream of the yield: the Streamdown configuration, the incremental Markdown cache, the fence tokenizer, and assistant-ui's update scheduling.

A separate finding, not fixed here

The entry opens with a deliberate side-effect import of the sidebar organization store. Without it the harness renders nothing and the page throws Cannot access 'SIDEBAR_ORGANIZATION_STORAGE_KEY' before initialization.

The underlying cycle is real app code, not a harness artefact: the chat barrel re-exports chat-page, which reaches the tour barrel, whose confetti helper imports the settings barrel, which imports the General tab, which imports SIDEBAR_ORGANIZATION_STORAGE_KEY back out of the chat barrel and reads it at module evaluation time in a top-level const PREFS_KEYS array. The app survives only because app-sidebar.tsx happens to import the theme toggler, and so the settings barrel, above its own chat import. Moving that one import block up reproduces the same white screen in the real app.

So this is a latent app bug worth its own change, not something to fix in a test-only PR. #8966 makes the settings tabs lazy, which cuts that edge and makes the workaround here unnecessary; the harness was verified to load clean with #8966 applied and the workaround removed. Whichever lands first, the root fix is for the General tab to read the constant from the store module rather than through the barrel.

Testing

• python3 tests/studio/playwright_stream_pacing.py: sixteen clean runs, six with Fix Studio CPU saturation on long streaming replies #8750 reverted, five with Studio: prevent long streaming Markdown stalls #7892 reverted, numbers above
• all three Playwright engines probed for CDP and longtask availability
• npm test (2,787 passed, including 5 new for the stall rule), npm run typecheck, npm run build
• dist/ confirmed to contain no reference to the smoke entry, and the entry is not in index.html's import closure, so neither the bundle nor the 75 MB budget moves
• pytest tests/studio/test_playwright_server_lifecycle.py tests/studio/test_autoscroll_harness_contract.py (27 passed) with the harness registered in both
• ruff check on the driver, npx eslint on the harness entry, clean

The harness had stopped loading, and CI could not tell us

Recorded here because it is the kind of thing that comes back silently.

After this branch merged main, the smoke page stopped loading entirely. Loading smoke-stream-pacing.html on the branch head produced an empty #root and a single page error:

Cannot access 'MarkdownText' before initialization

and the driver then died on a 60 second wait_for_function timeout. Every other smoke page on the same tree loaded fine, so it was specific to this one.

The cause is a second edge in the cycle described above, added by main rather than by this branch. #9014 introduced a module-scope literal in thread.tsx:

const ASSISTANT_PART_COMPONENTS = {
  Text: MarkdownText,

This harness enters the graph at markdown-text.tsx, which imports the chat barrel, which reaches chat-page, which reaches thread.tsx, which reads MarkdownText while that binding is still in its temporal dead zone. Module bodies evaluate once and live bindings start uninitialized, so a cycle is only harmless while every access is deferred into a function body, and this one is not. The workaround already at the top of the entry broke the first edge; main added a second and the trick went stale.

Fixed by importing the chat barrel before MarkdownText, mirroring the app's own entry order.

The part worth stating plainly: CI stayed green through all of it. The step that runs this harness carries continue-on-error: true, so a page that could not load, and a driver that timed out after 60 seconds, both reported as a passing job. The budgets this PR exists to enforce were not being enforced; nothing was being measured at all.

That argues for distinguishing the two failure kinds at the exit-code level, so that "the page is dead" can gate the job while the timing budgets stay advisory. That is a change to the workflow rather than to this harness, so it is not made here, but the current arrangement means a green Frontend CI is not evidence that this harness ran, let alone passed.

Separately, smoke-stream-pacing.html is a new HTML entry and did not load /crypto-boot.js, which #9075 added a test for. That was the live red on this PR and is fixed in the same commit.