Jev Ultrafast: Browser Use Puts Jev in the Browser Agent Loop

Browser Use, the company behind one of the most widely adopted open-source browser-agent libraries, has released Jev Ultrafast — a browser automation agent built around TypeSafe's Jev instead of a screenshot-reasoning LLM loop. The published headline result: a real, independently verified Google Flights search from Zürich to London, completed in 7.1 seconds at 1x playback, with actual generated text and page-load waits included, not edited out.

This is a genuinely different architecture from most browser agents explainx.ai has covered this year, including the ones benchmarked against GPT-6 Astra's browser-agent scores. Rather than having a generative model interpret a screenshot or a large chunk of page text and produce a free-form action description, Jev Ultrafast frames every step as a bounded decision — pick an operation, pick a target element — the same Choice-primitive pattern explainx.ai has already covered for Jev-based agent routing, applied here to the browser action loop itself rather than a higher-level routing decision.

TL;DR: What people are asking

The action space: a table, not a screenshot

Every step in Jev Ultrafast starts with an atomic DOM snapshot — a single browser read that captures every visible interactive control, its type, label, and current value, into a numbered table. Browser Use's own README example shows the shape of it: a combobox for departure city, a textbox for departure date, and so on, each with an index number. That table, not a screenshot, is what gets passed into a single TypeSafe request per decision cycle. Jev returns an operation and a matching target — CLICK [7], TYPE_TEXT [3] — which the executor then runs directly against the browser.

This is a structurally different design choice than the screenshot-and-reason pattern most browser agents use, including Tencent's BrowserSkill and the informally benchmarked agents in explainx.ai's Astra browser-benchmark coverage. Reading structured element state instead of pixels means the model never has to solve visual grounding — mapping a described action back onto screen coordinates — because every candidate target already has a known DOM reference attached to it before the decision is made.

Why it's actually faster, per the README's own accounting

Browser Use's documentation is specific about where the speed comes from, and it isn't primarily model latency:

• One request per decision cycle. The operation choice and the target choice come from the same TypeSafe call against the same observed state, rather than a multi-turn exchange where the model first decides what kind of action to take and then, separately, where.
• One browser call per snapshot, reading every visible control's name, value, and text atomically rather than issuing a separate protocol call per element check — the documented driver behind the roughly 10x reduction in browser protocol calls per task (1,092 → 101 in Browser Use's own six-run comparison).
• No screenshots in the default loop. Rendering and transmitting a screenshot, then having a model interpret it, is one of the more expensive steps in a typical browser-agent cycle; Jev Ultrafast skips it entirely for the decision path.
• Bounded waits instead of fixed sleeps. After typing into a combobox, the agent waits for visible suggestions, capped at 200ms; other interactions get at most two animation frames or 50ms — short, purpose-specific waits rather than a blanket delay after every action.
• Target validation before commit. Every selected click target is re-resolved against current page geometry, and covered or stale elements are rejected before input — added robustness that, per the README, still runs without materially slowing the loop down, since it reuses state already read for the decision.

Watch it: a real Google Flights search in 7.1 seconds

Browser Use published a video of a live run — Zürich to London on Google Flights, one natural-language goal, played at 1x speed with no cuts, generated city names filled in live, and loading waits left in rather than edited out. Watch the demo video on X.

Per Browser Use's own performance.md, the same policy also opened a specific Wikipedia article in 2.798 seconds and completed a local hotel search-and-filter task in 1.896 seconds. Browser Use is explicit that its six-run flight-search comparison — 3/3 passed for both the old and new agent versions, with the 25% median speedup — is "three repeats of one task on one browser profile, not a general reliability benchmark," a caveat worth taking at face value rather than extrapolating into a general claim about browser-agent reliability.

Small enough to actually read

Browser Use's README makes a point of listing the codebase's core files and what each one owns, which is worth including because it doubles as an honest map of where the architecture's complexity actually lives:

Chrome connects through a separate companion tool, Browser Harness, installed automatically by the project's uv sync step; a uv run browser-harness --doctor command re-establishes that connection if it drops, and Chrome's remote-debugging permission needs to be granted once when prompted. None of this is exotic infrastructure — it's the same category of setup any Chrome-automation tool requires — but it's worth knowing before assuming Jev Ultrafast is a zero-dependency drop-in.

What it deliberately can't do yet

Browser Use's README lists its own scope limits plainly, which is worth reading directly rather than inferring from the demo alone:

• A DONE decision still requires independent outcome verification — the agent doesn't trust its own completion signal without a separate check, the same caution explainx.ai has flagged for Jev's use as a verification checkpoint elsewhere in agent pipelines.
• The DOM reader handles common HTML and ARIA controls, not the full accessible-name specification — meaning some real-world sites with nonstandard markup may not expose elements cleanly to the element table.
• Shadow DOM roots, iframes, canvas-based UI, file uploads, pop-up tabs, nested scrolling regions, and arbitrary custom keyboard widgets are all explicitly out of scope for this version, per the README's own "Evidence and limits" section.
• Model output never becomes a selector, coordinate, shell command, or executable JavaScript — every executed action resolves back to an actual observed DOM node, a deliberate safety boundary the README calls out directly, relevant to the same tool-call risk-gating pattern explainx.ai covered for Jev-based agent middleware.
• Live examples and the recording scripts make paid API calls — the test suite itself runs offline, but reproducing the demo costs real TypeSafe and OpenRouter usage.

What this means for builders

If your agent stack already runs browser automation and screenshot-reasoning latency or token cost is the bottleneck, Jev Ultrafast is a concrete architecture worth studying even if you don't adopt the repo directly: the core idea — read a structured, indexed element table once per step and let a decision model score operations and targets against it, reserving full-LLM generation only for the step that genuinely needs free text — generalizes beyond browser automation to any agent loop where most steps are a bounded choice and only a minority require open-ended output. That's the same principle behind routing Jev calls into an agent's decision points instead of its generation steps, applied here at a much finer grain — per browser action rather than per high-level routing decision.

Teams evaluating it directly should treat the 7.1-second headline the same way explainx.ai has recommended reading any single-task benchmark from this ecosystem: as a real, verified result on one specific task, not a general throughput number to expect on arbitrary sites, especially given the DOM-reader's explicitly listed gaps around shadow roots, iframes, and nonstandard accessible markup.

Related on explainx.ai

• TypeSafe AI launches Jev: a "System One Model" that never hallucinates
• How to wire Jev into your agent pipeline for routing decisions
• Using Jev as cheap verification checkpoints in agent pipelines
• GPT-6 Astra scores 77.3% on a browser-agent benchmark, Claude Opus 5 gets 50.5%
• Tencent's BrowserSkill: an agent that drives a real browser
• Kev's real numbers: inside the open-source Jev clone's 0.8B/4B/9B family
• Is Jev's 200x-faster, 400x-cheaper claim actually true?
• Official source: browser-use/jev-ultrafast on GitHub

This post is sourced to Browser Use's public GitHub README (browser-use/jev-ultrafast) and its published demo video as of September 21, 2026. Timing and protocol-call figures are Browser Use's own reported measurements from performance.md; verify current numbers against the live repository before citing them elsewhere.