How Jev Ultrafast uses Jev

A flight search is a nice way to see a browser agent think. The goal in Jev Ultrafast is a one-way trip from Zurich to London, but Google Flights opens with Round trip selected. The mismatch is small enough to miss and big enough to spoil the result. What should the agent do next?

In the project's local inspector, a person gives the agent a task: find one-way flights from Zurich to London on September 20, 2026, for one adult in economy. Stop when matching options appear. Do not choose or book a flight.

Below that task box is the live browser, still on Google's Round trip form. The inspector lets you step through the choices or let the agent run; the creator's X post shows the run at full speed. I kept returning to the screenshot, where the task and the still-wrong trip setting share the same screen.

In the sampled Jev call, the first move is not to type Zurich. Jev favors CLICK with a probability of 0.77. Among the possible click targets, [12] Change ticket type. Round trip gets 0.88. These are two separate questions: what kind of action to take, then where to take it. Neither number predicts whether the whole search will succeed.

That click is only the start. In the project's recorded flight run, the agent submitted the search at 5.217 seconds and stopped at 7.073 seconds, after the results loaded. A separate check confirmed that matching one-way flights were visible. Those are the project's reported results for the full run; the screenshot above comes from a different run.

What happens between Jev and the click

I wanted to know what Jev was actually allowed to choose. The page reader finds visible controls and keeps references to them. The request builder numbers those controls and sends Jev the goal, the current page, recent actions, and questions about the next operation and its target. If Jev chooses CLICK, the app uses the click-target answer. Jev does not invent a selector or a screen coordinate.

The number [12] belongs to that one observation. Before the browser executor clicks, it checks that the page and nearby control still match, and that the control is visible and uncovered. If the page has changed too much, the agent loop observes it again and asks Jev for a new choice. The loop also marks a decision as consumed before acting, so a retry cannot repeat the click. Jev proposes a move; the browser code decides whether that move still makes sense.

The cities bring a wrinkle. Jev can choose TYPE_TEXT and a field, but a separate small language model writes the value from the goal and field context. In the recorded run, it supplied Zurich and London. The app checks that text result and the page before typing; it does not use a prepared list of cities. The trip type and date still need browser actions.

Jev eventually says DONE, but the example checks for itself: one-way, Zurich, London, the date, and visible matching results. DONE alone would not establish that the search worked.

The part I would borrow

Google Flights is one test for this browser agent. After each action, the page may change, and the agent needs another choice. Jev Ultrafast asks Jev for an operation and a target from controls the app just observed. I think that is a smart use of a fast decision model: a small question asked many times. The recorded flight run reached results that the app checked separately. The limit follows from the same design. Jev cannot choose a control the reader failed to find, and DONE cannot certify an outcome the app does not know how to check. I would borrow that division of work: let Jev make the next choice, and let the application stay responsible for acting on it and knowing when the task is done.