jev-ultrafast Narrows Browser Agent Actions

The seven-second flight search is not the most interesting part. Browser Use’s jev-ultrafast reports Zürich to London on Google Flights in 7.1 seconds, but the better lesson for agentic coding is how little freedom the model gets while still moving the browser.

The repository describes a browser agent with a dynamic, indexed action space. Give it a goal, and TypeSafe’s Jev chooses an operation and an element from the controls visible on the page. A smaller language model writes text only when the chosen operation needs typed input.

Read the loop before the stopwatch

Browser Use’s demo is narrow and concrete: one natural-language goal, actual text generation, loading waits included, and a separate check of the final result. That matters because browser-agent demos often blur planning, acting, waiting, and verification into one impressive video.

Here the README makes the action contract visible. Each observation produces a fresh table of page elements. Jev can choose from operations such as CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, and BLOCKED.

The model is not asked to write a selector or a script. It chooses a supported operation and a compatible target. The browser code then checks the selected control before acting.

That is the engineering shape worth studying. The policy proposes a move inside a bounded menu, and the runtime performs the unsafe part only after checking that the proposed target is valid.

Notice what the model cannot do

The clever part is the split between choice and execution. Jev does not get a blank terminal pointed at the browser. It gets a changing list of possible controls, then picks from that list.

That table is the difference between “the model controls a browser” and “the model selects from a browser state machine.” The second design is less glamorous, but I would rather debug it.

A real example is the Google Flights task. The goal can say Zürich to London, but the policy still has to work through visible controls: origin field, destination field, date controls, search or selection buttons. The repo’s claim is not that it has a special Google Flights script. The claim is that the action space is rebuilt from the observed page.

Keep the rough edges visible

The 7.1-second number is author-reported. I would not treat it as a general browser-agent benchmark, and Browser Use does not need it to be one for the design to be useful.

Google Flights is a good demo because it is familiar and full of real UI friction. It is also one site, one task shape, and one verification target. A different site with lazy rendering, custom widgets, anti-bot checks, or ambiguous labels may stress the loop in different ways.

There is also a cost to a bounded action space. If the observation misses a control, the agent cannot choose it. If the element table over-includes junk, the model has more noise to sort through. The safety comes from narrowing the possible actions, so the observation layer has to be good.

This is why I would compare jev-ultrafast less with chatty browser demos and more with harness design work such as Harness Design for Coding Agents, Measured. In both cases, the useful question is not whether the agent sounds smart. It is whether the system gives the model the right choices and checks the dangerous ones.

Try one small browser task

Use jev-ultrafast as a design specimen before treating it as infrastructure. Clone the repo, read the loop, and run one task whose success you can verify without human judgment.

Pick a boring page first. A local form with origin, destination, date, and submit fields is better than a production account flow. You want to see whether the element table, operation choice, target choice, and final check are understandable.

For Claude Code users, this is a good Design-step exercise in our methodology: ask the assistant to explain the action boundary, then make it point to the exact code path that executes the selected action. Do not start by asking it to improve the agent. Start by making the boundary visible.

A safe first pass looks like this:

1. Open the repo and find the loop that turns a page observation into an action choice.
2. Identify where the element table is built.
3. Confirm which operations can be emitted.
4. Trace where CLICK, TYPE_TEXT, and SELECT are checked before execution.
5. Run or inspect one deterministic task with an independent success check.
6. Record whether the failure mode is missing observation, wrong operation, wrong target, waiting, or verification.

That last line is the useful note. Speed is easy to over-read. Failure category tells you whether the architecture is sound enough to keep studying.

What changed and what to test

Copy this into your repo notes if you are evaluating the pattern rather than the demo:

jev-ultrafast evaluation note

What changed:
- The browser agent receives a dynamic table of visible controls.
- The policy chooses an operation and a compatible target.
- Text generation is isolated to TYPE_TEXT.
- Browser code checks the selected control before executing.
- The public flight demo reports Zürich to London on Google Flights in 7.1 seconds, with waits and text generation included.

What to test:
- Does the observation include the control a human would use?
- Are unsupported operations hidden from the model?
- Can the chosen target actually accept the selected operation?
- Is typed text generated only after TYPE_TEXT is chosen?
- Is success checked outside the model’s own narration?
- When the run fails, can you classify the failure without replaying the whole chat?

I would not add site-specific scripts as the first fix. That may make the demo faster, but it removes the thing worth learning from this repo: the policy should choose from structured page state, not from private knowledge of one website.

Further reading

• jev-ultrafast on GitHub
• MCP specification
• Cursor Agent docs
• Claude Code docs

Next step

Clone jev-ultrafast and trace one action from observed control to checked execution. If you cannot explain that path in five minutes, do not spend the next hour debating the benchmark number.