Kyle Jeong's Stagehand branch cuts Act latency to 0.46s
Jev picks the element, deterministic code does the clicking, and an LLM catches the uncertain calls.
Kyle Jeong put Jev inside Stagehand, the browser automation library, as a decision layer rather than an agent. Jev decides which element to click, which field to fill or which text to extract, and Stagehand's deterministic code does the actual work. In early evals on an experimental branch, median Act latency went from 1.97s to 0.46s, which Jeong puts at about 4.3x faster, and success across 240 real-site task runs went from 85% to 95.4%.
Extract is especially interesting because Jev can’t generate text.
The framing is the interesting part. Jeong's argument is that most browser actions are a choice among things already on the page, so Stagehand turns the page into a candidate list with context like labels, headings and table rows, and Jev picks from it. An instruction like typing San Francisco into the destination field gets broken into three smaller decisions, identify the action as a fill, identify the text, choose the destination input. Then deterministic code fills the field and checks the value afterwards.
Observe runs the same selection process. For a single element Jev picks one candidate. For several, Stagehand asks whether each candidate matches and batches the questions together, then returns the matches as executable actions.
Extract works around a hard limit
Extract is the case where the constraint shows. Jev cannot produce text, so it does not write the extracted values. It picks the elements that contain them, and Stagehand copies their text, parses numbers and resolves URLs. For repeated rows or cards, Jev identifies the fields in one item and the rest follows.
For people building on it, two caveats sit on top of those numbers. These are the integrators' own early evals, not a published third party benchmark, and the branch is explicitly experimental, with Jeong asking for feedback. More to the point, uncertain choices fall back to an LLM, so the median latency figure depends on how often that fallback fires on your pages. A workload with ambiguous, unlabelled DOM will pay the LLM cost more often than a travel form with a clean destination input, and neither the fallback rate nor the tail latency is in the post.