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:

press sends one key or chord, scroll moves the viewport or an element, wait_for holds until a condition is true, and navigate / back change the page.

A checkbox, a radio and a submit button are not text fields, so a value typed into one is a step that cannot work. When the element you want does not take the operation you chose, the operation is wrong for this step — not the element.

A control can also take more than one step without repeating itself: a date picker is opened, a day is chosen, and the choice is confirmed. That is three clicks, each decided from a table rebuilt after the page moved under the previous one.

Do not repeat a satisfied step

• A field that already holds the requested value is not typed into again.
• A checkbox, switch or radio already in the requested state is not toggled.
• A filter that is already set is not set again.

A populated field is not an applied search: submitting is its own step. A typed query is not a finished lookup either — when a suggestion list appears, the matching suggestion still has to be chosen. And a matching result does not prove a filter was set: check the control, not the outcome alone.