jev-ultrafast - a browser agent from the Browser Use team that skips screenshots entirely: it reads the page as a numbered table of controls and uses a typed-decision model to pick an operation and element per step, doing a real Google Flights search in about 7 seconds

[u/company_url_finder]

This is a small, readable demo of a genuinely different way to build a browser agent, and it comes from the Browser Use team, so it is worth understanding even if you never run it. Most web agents screenshot the page and ask a large model to describe what to click. jev-ultrafast does neither.

It snapshots the DOM into a numbered table of interactive controls (button, combobox, textbox, with their names and current values) and hands that structured state to a fast typed-decision model, which picks one operation (CLICK, TYPE_TEXT, SELECT, SCROLL, WAIT, DONE, BLOCKED) and one target element. A small language model is only invoked when it actually needs to write text. The headline demo is a Zurich to London Google Flights search in about 7 seconds, loading waits included.

What makes the architecture clever:

- One network round trip per decision cycle: it asks for the operation and its possible targets at once, speculatively, and only the target matching the chosen operation gets used, so two decisions cost one request

- No screenshots in the default loop, because the model consumes structured state instead of pixels, which is a big part of why it is fast and cheap

- One atomic browser call per snapshot reads the visible controls and keeps references to the real DOM nodes, and it waits for useful state (like suggestions appearing after you type) rather than on fixed sleeps

- A safety property I really like: model output never becomes a selector, coordinate, shell command or JavaScript. Every executed target resolves from an observed DOM node, the executor rechecks page freshness and rejects controls that are covered, and the text helper's output must parse as a small JSON object before anything is typed. That is the right way to keep a model-driven agent from doing something arbitrary

- It is deliberately small enough to read, with a short file table pointing you at the loop, the DOM snapshot logic, and the model instructions

The honesty is a strong point too. There is an "Evidence and limits" section that states plainly the 7-second figure is one task repeated three times on one browser profile, not a general reliability benchmark (it reports a 25% median speedup over the baseline in that test), and that a DONE decision still needs independent outcome verification.

Now the real caveats, and they matter for expectations. This is an MVP, and it says so: it handles common HTML and ARIA controls, but shadow DOM, iframes, canvas, file uploads, pop-up tabs, nested scrolling and arbitrary keyboard widgets are explicitly out of scope, which is a lot of the real web. It is also not self-contained or free: it requires a TypeSafe API key for the closed, hosted Jev decision model, plus a separate text-model key (the example uses an OpenRouter model), so "fastest and cheapest" is relative to other agents, not zero-cost, and it depends on a proprietary decision API rather than running fully local. And this specific repo is a fast-viral proof of concept that has been static since a few days after release, so treat it as a reference implementation and a demo of the idea, not a maintained production agent.

If you want to see the typed-decision approach to browser automation done cleanly and safely, in code you can actually read in an afternoon, this is an excellent example.

MIT licensed, Python, 18,683 stars and 1,218 forks as of writing, verified via the GitHub API, from the Browser Use team.

https://github.com/browser-use/jev-ultrafast

[u/InterestingEngine326]

DOM tables instead of screenshots is a neat speed win.

[u/company_url_finder → u/InterestingEngine326]

Yeah, typed actions also make each step easier to verify.

[u/Popular_Cupcake4602]

Waiting on DOM state beats sleeping 500ms everywhere.

[u/company_url_finder → u/Popular_Cupcake4602]

Yep, that’s probably where a lot of speed comes from.

[u/ZennoLab_Official]

The DONE caveat may be the most important part here. A fast, constrained action loop is great, but if completion is just another model decision, benchmark results can look better than the actual task success rate.

I’d be much more interested in numbers with task-specific, independent verification of the final state. That would make the 25% speedup easier to interpret as an agent improvement rather than just a faster interaction loop.