Jev-Ultrafast: Splitting Browser Decisions From Text Generation

Browser agents are slow for a boring reason: every step re-reads the page and asks a large model what to do next, and that model writes a full response even when the answer is "click the third button." jev-ultrafast from the browser-use team attacks that split directly. Jev reads the current DOM and picks the action and target element in a single request. Text models are called only when something actually needs typing.

It is the most-starred project in the Jev ecosystem, about 4,673 stars as of September 2026, and it was created only days before that count was taken. That combination of a big audience and a tiny track record is exactly when it pays to read the fine print. This article covers the design, the one published measurement, and the author's own caveats.

Key Takeaways

• The design separates "where to act" from "what to write." Jev handles the selection; text generation is delegated to small models.
• The published test is small. Six alternating runs of one Google Flights task.
• Reported medians: 9.450 s original, 7.092 s optimized, a 25.0% improvement, per the repo's performance notes.
• The author says it is not a broad benchmark. Three pairs give a sign-test p of 0.25, which the repo itself calls too few for a strong claim.
• Nobody has independently retested it as far as this series has found.

How the split works

The project summary describes an "ultra-fast browser agent using Jev for per-step DOM action decisions." In a conventional loop, the model does both jobs at once: interpret the page and write the action. Here the per-step decision is a typed choice over the elements and actions available, which is the kind of closed-set question Jev is built for (see what Jev is). When the step is "type a destination," the project calls a text model for the string.

The stated benefit is that this separates UI navigation from text generation and cuts redundant page evaluations. That is a design claim, and the sensible reading is: fewer big-model round trips on steps that are really selections.

What the benchmark actually shows

The repo's performance notes describe the test plainly:

The notes then list their own limits. Three pairs are too few for a strong statistical claim (two-sided sign-test p = 0.25). It is a small controlled-input comparison, not a broad agent benchmark. Live Google responses, network conditions and browser caches were active. Initial navigation is excluded from timing. And the DOM reader does not implement the full accessible-name algorithm or traverse shadow roots or frames.

Note also what the comparison is: two versions of the same runtime, not Jev-versus-some-other-agent. It tells you the optimized runtime was faster on this task, not that every browser task will see 25%. The headline "~7.1 seconds" for a flight search is accurate to that one setup.

Any site with heavy shadow DOM or iframes is a place to test carefully, given the stated reader limitation.

How to try it responsibly

• Run your own task, not theirs. Time at least ten pairs so your result is not a coin flip.
• Measure success rate, not only speed. A faster agent that fails more is not faster.
• Keep the first navigation in your timings if your users will feel it.
• Treat browser control as a permissioned action: an agent that can click can also buy.

For the broader picture of who else is building browser and desktop agents on Jev, see Jev-powered browser and desktop agents. The project is also listed on aiskill.market as jev-ultrafast.

What to do next

1. Read the performance notes yourself; they are short.
2. Reproduce with your own workflow and record medians and failures.
3. Pair it with a routing layer if you want to escalate hard steps; see routing by difficulty.
4. Track the wider ecosystem on the awesome-jev-projects radar.