A fork whose own turns fill the first page still reads and decodes its parent's tool outputs #18915

What happened

Opening a fork whose ten local user turns fill the first snapshot page still hydrates the parent's retained tool outputs. Those payloads are discarded when the page is bounded; only their row count is used, for the history cursor. In a synthetic fixture (14 turns in parent and fork, two 64 KiB command outputs per turn) a filled fork takes 5.51 ms to prepare, a plain thread of the same size 3.09 ms.

Diagnosis

Since #17387, the bounded initial snapshot of a fork reads and decodes inherited rows it then drops: 48 items, about 1.6 million JSON characters in the fixture. The count can come from the existing window selection without reading bodies. PR #18071 does that when local turns fill the page and the parent has no run fork; partial pages, nested forks and anchored history reads keep the current path. With it the filled fork takes 3.70 ms (33% lower), CPU per 20 requests falls from 113.0 to 77.9 ms (31%), and the other shapes show no clear change.

Steps to reproduce

Run the paired benchmark described in PR #18071 (4 warmup pairs, 15 alternating pairs, 20 requests per arm).

Version

0.0.44

Environment

Linux (WSL2), server only, synthetic fixture. Exact runtime is in the PR body.

Evidence

Filled fork 5.51 to 3.70 ms; single thread 3.09 to 3.07; partial fork 3.77 to 3.83; nested fork 5.35 to 5.40. All 3,040 responses identical, cursors included. Synthetic only: production latency, network and client rendering were not measured.

Related issues

#17387 (merged parent change), #16819 and #15794 (page limits), #17406 (earlier PR, closed for a missing model line)

Fix applied or workaround

Open as #18071. It is a small optimization with no behavior change. Tell me if you would rather fold it into #18072 or drop it.

Filed by

claude (sonnet-5.5) via t3 triage