Jev Ultrafast: 7-Second Browser Agent at $0.0039

On 16 September, the team behind browser-use, the 114,000-star Python library for agents that drive a browser, published Jev Ultrafast, an MIT-licensed browser agent that completes a real Google Flights search from Zürich to London in 7.073 seconds. The repository was 15 hours old and had 873 stars and 45 forks at the time of writing. It is built on Jev, the decision-only model from TypeSafe AI that we covered on 15 September in our analysis of its 0% hallucination rate and 67.8% accuracy.

The headline number travelling with the launch is the 7.1-second flight search. The more interesting number is buried in the project's own measurement file: median browser protocol calls fell from 1,092 to 101, a 90.8% reduction, and that bought a 25.0% reduction in wall-clock time. Those two figures do not match, and the gap between them is the most useful thing this release teaches. We did the decomposition the repository stops short of performing.

What browser-use actually shipped

Jev Ultrafast is a small agent loop, not a model. Each cycle takes one atomic DOM snapshot and turns it into a numbered element table: every visible control with its role, its accessible name, and its current value. Jev then picks one operation and one target element in a single request. The operations are a closed set of eight: CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, and BLOCKED. Only operations and targets that are actually available on the current page are offered.

The design trick is that the operation question and the target questions go out together, speculatively, in one network round trip, using the speculative fan-out pattern in TypeSafe's documentation. Each target head contains only elements compatible with its operation. If Jev returns CLICK, the click target is used and the type target is discarded. Two decisions, one round trip.

There are no screenshots in the default loop. Jev consumes structured text state, not pixels, which is the single largest architectural difference from most current browser agents. Chrome connects through Browser Harness, the same org's self-healing connection layer. Notably, model output never becomes a selector, a coordinate, a shell command, or executable JavaScript: every executed target resolves from a node that was already observed, and the executor rechecks page freshness and click occlusion before acting.

A 10.8x cut in browser calls bought 1.33x on the clock

The project's performance report documents six alternating runs, three per arm, on one task and one Chrome profile, with both arms pinned to TypeSafe jev-1.13.0 and inception/mercury-2.5 at a 1120x780 viewport. Here is what changed, and what it was worth.

Eliminating 991 browser protocol calls and 5 model requests saved 2.358 seconds. That is a poor return on a 10.8x reduction, and the reason is visible in the recording data if you divide it out. The recorded 7.073-second run contains 17 Jev requests at a median latency of 178 ms, which is 3.026 seconds, or 42.8% of the entire run, spent waiting on the decision model. The two text-helper calls that generated the city names took 581 ms for "Zurich" and 346 ms for "London", another 0.927 seconds. Model latency alone is 3.953 seconds, or 55.9% of the clock.

Then there is the tail. The report states that search executed at 5.217 seconds and verified completion landed at 7.073 seconds. That final 1.856 seconds, 26.2% of the run, is Google's results page loading and the completion decision. No amount of agent engineering touches it.

Roughly 82% of the run is model latency plus a page load, neither of which the snapshot rewrite addresses. The browser chatter that was cut by 90.8% was competing for a slice of the remaining 17.9%. This is ordinary Amdahl's law, and it sets a hard ceiling: even an agent with zero browser overhead and zero thinking time still owes Google about 1.9 seconds on this task. Chasing protocol-call counts is close to finished as an optimization; the next second has to come out of model latency or out of the number of round trips, which is why cutting 22 requests to 17 matters more than cutting 1,092 calls to 101.

Where the $0.0039 actually goes

browser-use's launch thread put the all-in cost of the flight search at $0.0039. The performance report declines to compute it, noting that the TypeSafe responses carry token counts without a billed dollar amount, and reports only the $0.00006272 that OpenRouter charged for the two text calls. The missing half is recoverable, because the report records 90,558 Jev input tokens and 6,325 output tokens, and Jev's launch pricing is $0.042 per million input tokens with output tokens free.

That gives $0.0038034 for Jev against $0.00006272 for the text helper, or $0.0038662 in total, which rounds to the $0.0039 the project quotes. Reproducing the published figure from the component numbers is what confirms the split is real, and the split is the surprise.

The model marketed as the cheap, fast decision layer is 98.4% of the bill. The general-purpose LLM that everyone assumes is the expensive part is 1.6%. The mechanism is not the per-token price, it is volume: Jev sees 5,327 input tokens per request because the entire element table is re-sent every cycle, 17 times, while Mercury 2.5 is handed two tiny prompts and asked for one city name each. We covered that model's economics when it launched in our write-up of the Mercury 2.5 preview.

The practical consequence for anyone costing out an agent: your spend scales with page complexity, not with task difficulty. A dense enterprise dashboard with 400 controls will cost multiples of a flight search regardless of how simple the goal is, because the element table is the payload. State compression, not model selection, is the lever.

The System One model still cannot write a sentence

Jev is what TypeSafe calls a System One model. It answers typed questions against state and returns structured results: a Choice with a probability for each option, a Score, or a Noul probability. It does not generate text. TypeSafe's own documentation is explicit that the model works best on atomic, well-scoped questions answerable in seconds, and recommends decomposing complex judgments rather than asking them holistically.

Jev Ultrafast is the first public demonstration of what that constraint costs in practice. The moment the agent needs to type the word "Zurich" into a combobox, Jev cannot help, and a second model has to be wired in for that one job. The architecture is not a decision model replacing an LLM. It is a decision model plus an LLM, with a routing rule between them, and a second API key in the .env file.

The repository is candid that picking the text helper took work. An earlier probe rejected one model that swapped origin and destination, and another that emitted commentary instead of valid JSON. Mercury 2.5 was chosen with reasoning disabled, and the report notes Gemini 2.5 Flash Lite and Gemini 3.1 Flash Lite also returned correct values on a six-call probe. This is the hybrid pattern we traced in our comparison of diffusion LLMs for agent work, and it is the same division of labour that orchestration layers like Sakana Fugu are built around: a fast, cheap, calibrated router in front of slower generative models.

Run the 7-second agent yourself

The repository is genuinely small enough to read, which is rare for an agent framework. Six files carry the whole loop. To run it:

1. Clone the repository and run uv sync. This also installs Browser Harness, which handles the Chrome connection.
2. Copy .env.example to .env and add TYPESAFE_API_KEY plus TEXT_MODEL_API_KEY. The example configuration expects an OpenRouter key for the text helper.
3. Run uv run jev and open the local inspector at 127.0.0.1:8766.
4. Click Start demo, then Run automatically. Use Choose next instead if you want to pause before each execution and read the operation and target probability distributions.
5. Run uv run browser-harness --doctor if Chrome does not connect, and allow remote debugging when prompted.

The library form takes a URL and a natural-language goal and yields state dictionaries with elapsed milliseconds and status, so you can drive it from your own script. The bundled examples point it at Wikipedia and at a local hotel fixture, which completed in 2.798 and 1.896 seconds respectively. Both are smoke checks rather than matched comparisons.

Worth knowing before you budget time: the inspector's probability view is the actually novel debugging surface here. Most browser agents give you a screenshot and a guess. This one shows you the ranked element table the model saw and how confident it was in each candidate, which turns "the agent clicked the wrong thing" into a question you can answer.

What these numbers do not prove

The report is unusually honest about its own limits, and repeating them matters more than the headline. Three matched pairs on one task with one browser profile is a two-sided sign test at p = 0.25, which the authors state outright. That is not a significant result, and it is not a general agent benchmark. Google, network conditions, routing, and browser caches were all live during measurement.

The capability gaps are real too. The DOM reader handles common HTML and ARIA controls but does not implement the full accessible-name algorithm and does not traverse shadow roots or frames. Canvas, file uploads, pop-up tabs, nested scrolling, and arbitrary keyboard widgets are unsupported. A DONE decision is explicitly never treated as evidence of success, which is why the flights example runs an independent checker against the actual route, date, and visible results. That verification discipline is the part most worth copying, whatever agent stack you are on.

Frequently asked questions

Is Jev Ultrafast free to use?

The code is MIT licensed and free. Running it is not: you need a TypeSafe API key for Jev and a key for a text model. The measured flight search cost about $0.0039 in model calls, of which 98.4% was Jev.

Why is the decision model more expensive than the LLM here?

Volume, not unit price. Jev receives the full element table on all 17 requests, averaging 5,327 input tokens each, while the text helper gets two short prompts. Cost tracks page complexity rather than task difficulty.

Does it need screenshots or a vision model?

No. The default loop sends structured DOM state only. The inspector can opt into screenshots for debugging, and the demo video uses a separate screencast, but neither is in the agent's decision path.

How does this compare to Playwright or Chrome MCP agents?

Those expose browser primitives to a general LLM that writes the actions. Jev Ultrafast inverts it: a constrained model picks from a pre-validated list of legal operations and observed elements, and model output never becomes a selector or a coordinate. We compared the MCP-based approaches in our Safari, Chrome, and Playwright MCP breakdown.

Can it book a flight or complete a purchase?

Not as shipped. The flights example searches and verifies results, and explicitly does not select or book. Uploads, new tabs, and many keyboard widgets are outside this MVP.

Is 7.1 seconds a benchmark result?

No. It is one recorded run on one task, with a 25.0% median improvement measured over three matched pairs at p = 0.25. Treat it as a demonstration of an architecture, not as a competitive score.