Browser Use with Jev + Stagehand

Jev picks the next action from the accessibility-tree state; Stagehand executes it in the remote browser. The author says Choice chooses the action, Noul judges completion or action readiness, and Score reads progress, so several typed questions ride along in one request.

The post says the task cost $0.001 without breaking it down, and a browser loop takes many steps over a page that keeps changing. Treat it as the author's figure for one demo run rather than a per-decision price you can plan capacity against.

It gates on confidence: the author says only actions Jev decides are worth doing get executed, and links TypeSafe's confidence-gated routing doc. Nothing states what sits at the low end of that gate, whether it means a retry, a fallback, or stopping the run.

The request shape is in the thread: model jev-latest, a state block holding task, page, browser, and recent actions, plus a questions block for operation, click_target, and input_target. The task itself is not published, so you can copy the shape but not the eval.

Kyle Jeong, who says he does growth engineering at Browserbase, the company behind Stagehand. So it is a first-party demo of Browserbase's own tool paired with Jev rather than an independent build, which is worth noting when reading the cost and speed claims.

It is the state Jev reads. Rather than screenshots, the harness serializes the page's accessibility structure and sends it alongside the task, browser details and recent actions, which keeps the input text-only and matches Jev's text-only interface. The chosen action then goes back to Stagehand to execute.

It makes the demo cloud-to-cloud: the page state is serialized and sent to Jev, the chosen action returns to Stagehand, and Stagehand drives a hosted browser rather than a local one. That removes local setup but adds a network hop the $0.001 figure does not account for.