jev-ultrafast

Jev Ultrafast

browser-use covers the mechanics — snapshots, refs, coordinates, permissions, the observe/act/observe loop. This is the decision policy on top of them: how to choose the next action so that a run spanning dozens of steps still finishes quickly.

It comes from browser-use/jev-ultrafast, where a goal runs on an indexed action space: one observation, one decision, one action, with the operation and its target chosen together.

One table, one decision, one action

Take a snapshot, then write the candidates out once as a numbered table — one index per element, the value it currently holds, and the operations it can take:

[1] e3   button    "Change ticket type · Round trip"
[2] e5   combobox  "Where from?"  value="San Francisco"
[3] e7   combobox  "Where to?"    value=""
[4] e9   textbox   "Departure"    value=""
[5] e12  button    "Search"

Then choose the operation and its target in the same step, and make one tool call. Two decisions, one observation: the target cannot come from a table the operation did not see, and a step costs one snapshot instead of two.

The numbering is the point, not decoration. One index per element makes a checkbox and its label one target instead of two, and each line carries the current value — so "is this step already done" is answered by the table rather than by memory.

Do not take a fresh snapshot between deciding and acting. Reuse the one you have: that single observation per step is what makes the loop fast, and it stays valid until the page changes.

The index is local to its snapshot, like the ref it points at. When the page moves, rebuild the table; never carry an index across observations, and never act on an element that was not in the table. If the snapshot reports elements omitted by its cap, the control you want may be past it — raise max_elements or scroll to it rather than guessing at a target.

Match the operation to the element

Only three operations change a page, and each takes its own kind of target: