Yuval Avidani
Author
A browser agent from Browser Use searched for flights from Zurich to London on Google Flights in 7.1 seconds, from the first prompt to results on screen. The project is called jev-ultrafast, it went up on GitHub on September 16th, and within a month it collected over 23,000 stars. In this piece we're taking that exact search, Zurich-London, and walking through it end to end: how a browser agent "sees" a page, why this used to be slow and expensive, what exactly changed, how to run it yourself, how much each step costs, and when you really shouldn't use an agent like this at all.
One moment of precision before we start: the agent doesn't book a flight. It fills out the search form, lands on the results screen, and stops there. Exactly as the project's README says, it "doesn't choose or book a flight." That matters, and we'll come back to it at the end.
What even is a browser agent
A browser agent is software that connects an AI model to a real browser, so the model can click, type and scroll on websites for us — for anyone who needs to do tasks on sites that don't have an API. Think of it like a personal assistant sitting in front of our computer: we say "find me a flight from Zurich to London on September 20th," and it opens the site and fills in the fields.
Let's break that down. To work, the agent needs three things:
Eyes. The way it "sees" the page. There are three main approaches here. The first is the DOM (the tree structure of all the elements on a page, like a building's skeleton). The second is the accessibility tree, a filtered version of the DOM that the browser builds for screen readers used by blind users, containing only what's clickable or readable: buttons, fields, links. The third is a screenshot sent to a model that understands images.
Hands. A closed set of actions: click, type, select from a menu, scroll, wait, and declare "I'm done."
Brain. The model that decides, at every moment, which action to take and on which element.
All of this runs in a loop: look at the page, decide, act, look again. In our Zurich-London search, the agent sees a "Where from?" field, decides to type in it, types, sees a suggestion list pop up, picks Zurich, and moves to the next field.
Why this used to be slow and expensive
Until recently, the "brain" in that loop was a large language model, and it turns out that's exactly the problem. A language model (LLM) is a model that generates text, word by word. When you ask it to decide on a click, it writes out a full answer, sometimes with an explanation, and then some other piece of code has to parse that text and turn it into an action. Think of it like asking someone "left or right?" and getting back a whole paragraph.
That costs you three things. The first is time: every step is a call to a big model that takes seconds, and a twenty-step task turns into a minute or more. The second is money: on every step you send the model the entire page state, sometimes a screenshot too, and you pay per token (the unit of text that models charge by). The third is reliability: a model generating free-form text can also return something that doesn't match any element on the page.
And the browser side was heavy too. In jev-ultrafast's performance doc, the developers document that their original version kept re-reading the accessibility tree, resolving hundreds of nodes on the page, and invalidating decisions on every tiny page change, including animations. The improved version dropped from 1,092 browser calls to just 101, on the exact same task. And to be fair: the big-model-plus-screenshots approach also works, and it's still the most flexible for complicated sites. It just pays for that flexibility in time and money.
What changed: a model that decides, and a small model that just types
Here's the cool part — jev-ultrafast splits the brain in two.
The first part is Jev, a model from a company called TypeSafe. According to their docs, Jev is a "System One" model (the name borrowed from Daniel Kahneman's "Thinking, Fast and Slow," referring to fast, intuitive thinking). It doesn't write text at all. It receives a state and closed-ended questions, and returns a choice from a list, with a probability for each option. Think of it like a multiple-choice quiz instead of an open essay: there's no way to "answer something else."
At every step, the agent captures the page not as an image but as a numbered table of actionable elements, for example [2] combobox "Where from?" and [3] combobox "Where to?". Then it asks Jev, in one single network request, several questions in parallel: which action (CLICK, TYPE_TEXT, SELECT, scroll, WAIT, DONE, or BLOCKED), which element to click if it's a click, and which to type into if it's typing. The questions about the element are "speculative": all of them get asked up front, and only the one matching the chosen action actually gets used. Two decisions, one network round trip.
The second part is a small, fast language model that only comes into play when the action is TYPE_TEXT. In the demo it's Mercury 2.5 by Inception, via OpenRouter, with thinking turned off. In the official recording it generated the word Zurich in 581 milliseconds and London in 346.
And here's one more decision that saves a ton: no screenshots in the loop at all. The agent reads the page as structure, in a single browser call, and sends the model only visible text. There's something nice on the security side too: the model's output never turns into a selector, coordinates, a shell command, or JavaScript code. It just picks a number from a table our code built.
Getting hands-on: running it yourself
The setup is straight from the official README. You need uv (Python's fast package manager), Chrome, and two keys: a TypeSafe key for Jev, and an OpenRouter key for the text model.
In plain words: clone the repo, run uv sync, copy the config file, fill in TYPESAFE_API_KEY and TEXT_MODEL_API_KEY, and run uv run jev. Then open http://127.0.0.1:8766, click Start demo, then Run automatically. In the UI you can watch in real time the numbered element table, the probabilities for each action and each element, and what actually got executed. There's also a Choose next button that pauses before every action — that's the best way to really understand what's happening under the hood.
The connection to Chrome goes through Browser Harness, another Browser Use project that installs automatically and hooks the agent up to our actual Chrome. Worth noting: that means the agent works with our profile, including logged-in accounts. If the connection doesn't work, run uv run browser-harness --doctor and approve remote debugging in Chrome.
How much each step costs
Let's break down the Zurich-London search according to the official performance doc. In the recording there were 17 requests to Jev, ten actions on the page plus one WAIT, and two calls to the text model. Jev's median response time was 178 milliseconds. The search click happened after 5.2 seconds, and the agent declared "done" after 7.07 seconds — and that includes Google's page load time.
On the cost side, the recording consumed 90,558 input tokens and 6,325 output tokens on Jev. TypeSafe's models page states Jev costs $0.042 per million input tokens, with output free. Our math: roughly $0.0038 for all of Jev, meaning about $0.0002 per decision. The two text calls cost, per OpenRouter, $0.00006. Altogether, the entire flight search cost about 0.4 cents, not counting the browser's own compute cost. Worth being precise here: the Jev figure is our own calculation based on the price list, since TypeSafe didn't return an actual billed amount — and the developers themselves flag this.
To get a sense of scale, we calculated what the exact same token count would have cost on other models, per their official pricing:
The same tokens on Claude Sonnet 5.5 ($2 per million input, $10 for output) would have cost around 24 cents, and on Gemini 3.1 Flash Lite around 3.2 cents. This is an illustrative comparison: an agent built on a big model would behave differently and generate a different token count. But it illustrates why a decision model that doesn't write text changes the whole economics of browser agents.
And on speed: across six alternating runs with the same models, the median time dropped from 9.45 to 7.09 seconds — a 25% drop. The developers themselves note this is three repetitions of one task on one profile, not a general reliability benchmark. That same setup opened a Wikipedia entry in 2.8 seconds.
When not to use a browser agent
Here's the part that matters most to me. A browser agent is a great hammer, but not everything is a nail.
When there's an API. If a service has an official programmatic interface, it's almost always faster, cheaper, more stable, and more permitted. A browser agent is a solution for sites that don't have an API — not a replacement for an API that already exists. Google Flights' page can change tomorrow morning; a flight provider's API doesn't.
When there's a CAPTCHA or bot blocking. A site that puts up a CAPTCHA ("prove you're not a robot") is telling us something clear: it doesn't want automated traffic. There are tools today built specifically to get around this. The invisible_playwright_mcp project, for instance, collected around 2,800 stars in under three weeks, and describes itself as an MCP server that's "undetected by anti-bots and captchas." Scout by Outcrawl, an open-source agent that launched on October 13th, offers CAPTCHA-solving in its cloud too, as does Browser Use's own cloud — which honestly states that no configuration guarantees success against every CAPTCHA. In my view, bypassing a protection mechanism on a site that isn't ours isn't a technical question, it's a legal and ethical one, and it's worth stopping to think about before you touch it.
When the terms of service forbid it. Google's terms of service, for example, explicitly say you can't use automated means to access content against the instructions a site publishes for machines, like a robots.txt file. Before you point an agent at a site, read its terms.
When the mistake is expensive. This agent doesn't book a flight, and that's not an accident. The developers explicitly write that even when the agent declares DONE, that's not proof of success — which is why the demo includes an independent checker that separately verifies the route, date, and results. Payments, deletions, and form submissions need a human to sign off.
And there are technical limits worth knowing too: per the README, the current version doesn't support shadow DOM, iframes, canvas, file uploads, new tabs, or nested scrolling. This is an MVP (a minimal first version), not a finished product.
My take: the agent isn't a model, it's a system
Bottom line, the story here isn't "a faster model." The story is architecture. Instead of letting one giant model do everything, the task gets split up: deterministic code builds a table of what's possible, a decision model picks from it, a small model writes text only when needed, and separate code double-checks that the click is still valid before it actually happens. That's how you get to seven seconds and under half a cent — not because one model suddenly got smarter.
To me, this is also the broader lesson for anyone building agents: anywhere we're letting a big model choose from a closed list, there's time and money to save. And in the same breath, keep the caveats in mind: three runs on one task isn't general proof of anything, Jev still can't see images, and complex sites will still need the heavier approach.
So — what's the task we do manually every week on some site with no API, that we'd hand first to a seven-second agent?
Want to go further with this?
I break down the whole foundation of agents, MCP, and tools that connect Claude to the real world, in depth, in my course Practical AI with Claude, in Hebrew. If you want to build agents like this yourself straight from the terminal, check out Claude Code Mastery, in English.
I post browser agent demos on YouTube and LinkedIn, and quick updates on X, Instagram, and TikTok. My code is open on GitHub.