Jev Ultrafast Explained: a 7-Second Browser Agent

Jev Ultrafast is a browser agent that treats Jev as a fast decision layer. The page becomes a numbered table of controls. Jev picks the next operation and which observed element it applies to. A small language model writes a string only when the operation is TYPE_TEXT. The browser harness executes that one choice after its own checks.

The repository is browser-use/jev-ultrafast. License, language, and the GitHub star snapshot captured on 24 September 2026 are on the Jev Ultrafast project profile. Star counts move; the profile stores the capture date so this guide does not keep a second copy of the numbers.

This page is the overview. The request shape and guards are in How Jev Ultrafast works. The reason a decision model fits this job is in Jev as a decision layer. A short build walkthrough is in the browser-agent tutorial.

What one step looks like

A traditional browser agent often sends a screenshot, or a large HTML dump, to a general model and asks it to invent the next action: a selector, a coordinate, or a block of JavaScript. Ultrafast does not do that in the default loop.

The snapshot is a fresh element table, in the form the README prints:

[1] button    Change ticket type · Round trip
[2] combobox  Where from?        · San Francisco
[3] combobox  Where to?          · empty
[4] textbox   Departure          · empty

Jev then chooses among operations the page can actually support:

CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, BLOCKED.

If the choice is CLICK, a second answer in the same TypeSafe response names the element, for example [7]. The executor clicks that observed node. It does not accept click("#search > div:nth-child(4)") from the model.

The 7.073-second Flights run

The current demo video is a Google Flights task: one-way, Zurich to London, 20 September 2026, one adult, economy, stop when matching options are visible. docs/performance.md times that recording at 7.073 seconds at 1× playback.

The clock starts at the first prediction after the initial homepage observation. It includes Jev calls, generated city names, browser work, stale decisions, and loading. It excludes browser setup, the initial navigation, and a fresh check that runs after the timed section. That later check looks for the one-way setting, Zürich, London, the date, and visible flight options. The agent does not pick a fare or book.

Inside that recording the authors report:

The token line is not a TypeSafe invoice. The performance note says TypeSafe responses include token counts without a billed dollar amount, and browser costs are excluded. The $0.00006272 figure is only the text-helper charge OpenRouter reported for those two calls. The recorded helper was inception/mercury-2.5 with reasoning disabled. The run used TypeSafe jev-1.13.0.

What the paired timing actually shows

The same document reports six alternating runs of that one Flights task, on one existing Chrome profile, both arms using the same goal, checker, 1120×780 viewport, model, and budgets. Initial navigation is excluded. Every attempt passed.

Median task time fell about 25%. Median TypeSafe requests fell from 22 to 17. Median browser protocol calls fell from 1,092 to 101. The optimized arm was faster in all three pairs. The authors give a two-sided sign-test p = 0.25 and write that three pairs are too few for a strong statistical claim. Google, the network, routing, and browser caches were live.

Two other checks are listed separately, and the authors call them smoke checks rather than matched speed tests:

Why the loop can be short

The speed work is the whole loop, not a claim that Jev alone is magic.

• The default agent does not send a screenshot to a vision model. The inspector can show screenshots; the demo video uses a separate screencast. Neither one drives the policy.
• One browser call reads visible controls, names, values, and text, and keeps references to the real DOM nodes. Off-screen article bodies and footers are not stuffed into the model state.
• Operation and target are one TypeSafe request. That pattern is speculative fan-out.
• Jev does not generate Zurich. It decides that the next operation is TYPE_TEXT on a particular field. Mercury, or another configured helper, returns {"text": "Zurich"}.

There are no site-specific action scripts and no prepared field strings in the policy. The Flights example supplies a goal and then checks the outcome on its own.

What the model is allowed to say

Model output never becomes a CSS selector, a coordinate, a shell command, or JavaScript. Every executed target is resolved from a node that was in the snapshot. Before a click, the executor rechecks page freshness, the document, form values, the target, nearby context, current geometry, and whether something covers the control.

Text-helper output must parse as a small JSON object before anything is typed. Page text is treated as untrusted data, not as new instructions.

DONE is still only the model’s choice. The README says a DONE choice needs independent outcome verification. A legal operation can also be the wrong operation.

What this MVP does not drive

The DOM reader covers common HTML and ARIA controls. It does not implement the full accessible-name specification. The README leaves these outside the MVP:

• shadow roots
• frames and iframes
• canvas
• uploads
• pop-up or new tabs
• nested scrolling
• arbitrary keyboard widgets

Owned tabs share the existing Chrome profile. The step budget in questions.py is MAX_STEPS = 60.

How to talk about it

Use Ultrafast when you need a concrete public example of Jev choosing among actions a program already enumerated. Pair that with the authors’ own limits: one task family in the timed comparison, three pairs, p = 0.25, and a DONE signal that is not proof.

Next: architecture and fan-out, or the decision-layer concept.