Breaking Down Jev Ultrafast: Why This Browser Agent Can Search Flights in 7 Seconds

How much can a browser Agent accomplish in 7 seconds? The open-source project Jev Ultrafast offers a concrete answer: open Google Flights, enter Zurich and London, select one-way, and retrieve flight results — the official demo recording clocks this entire sequence at 7.073 seconds. That timer starts from the Agent's first decision and ends when the correct results appear on screen, excluding the initial browser launch and any post-task operations. The project crossed 15,000 stars in under a week. So what exactly did it cut out to run this fast?

Turning Web Pages from "Reading Comprehension" into "Multiple Choice"

A typical browser Agent works a bit like re-reading the entire test paper before answering each question. No matter how long the page is, how many buttons, images, or text blocks it contains, the model has to scan it all first. After each click changes the page, the model has to scan again. When every round includes screenshots, page content, and tool descriptions, the latency compounds with each step.

Jev takes a different approach: it turns the page into a multiple-choice question. It extracts all currently interactive elements and arranges them into a numbered list — item 1 is a button, item 2 is an input field, item 3 is a dropdown menu — along with each item's label, current value, and available actions. The model doesn't need to guess mouse coordinates or write CSS selectors on the fly. It only needs to answer two things: what action to take, and which number to pick. For example: "click item 7."

Only when text input is required does it invoke a smaller model to generate the content. According to official records, generating "Zurich" took 581 milliseconds and "London" took 346 milliseconds. This division of labor compresses most decisions into a single simple selection, dramatically reducing the amount of information the model needs to process at each step.

Traditional browser Agents typically rely on one of two perception methods: screenshots (where a vision model analyzes the page pixel by pixel) or the DOM tree (where the full HTML structure is serialized and fed into the model). The first is bottlenecked by multimodal model inference speed; the second is constrained by context window limits, since modern web pages can contain thousands or even tens of thousands of DOM nodes. Jev's approach is essentially a semantic filtering layer: it extracts only the interactive elements currently visible in the viewport (such as button, input, select, [role=button], etc.), ignores purely presentational nodes, numbers them, and serializes them into a compact text list. This can reduce the token count fed to the model to just a few percent of the full DOM, naturally shortening inference latency. The trade-off: elements identifiable only through the accessibility tree or specific CSS selectors — such as Canvas-rendered controls or nodes inside Shadow DOM — get filtered out, which is the root cause of its tendency to get stuck on complex web pages.

Two Sources of Speed: Read Less, Call Less

The first speed boost comes from the model seeing less. By default, screenshots aren't sent to the model; content below the fold and footer text are excluded; and reading the current interactive element space requires only a single browser call. Minor page animations don't trigger a full re-evaluation of the current round.

The second speed boost comes from fewer round trips to the browser. The team ran three trials each with the pre- and post-optimization versions: the original version had a median time of 9.450 seconds; the optimized version clocked 7.092 seconds — a reduction of about 25%. TypeSafe requests dropped from 22 to 17; browser protocol calls fell even more dramatically, from 1,092 down to 101.

It's worth noting that all three trials used the same flight query and the same browser configuration. This demonstrates the optimization is effective for this specific task, but doesn't prove identical speedups will occur on any arbitrary website. The project also includes two smaller benchmarks: opening a specific Wikipedia page took 2.798 seconds, and filtering a local hotel listing page took 1.896 seconds — but neither includes a side-by-side comparison with the older version under identical conditions.

The reduction in browser protocol calls from 1,092 to 101 relates directly to how the Chrome DevTools Protocol (CDP) works. CDP is the underlying communication protocol used by browser automation libraries like Playwright and Puppeteer. Every click, screenshot, DOM read, and network-idle wait corresponds to multiple CDP message round trips. Too many round trips not only increase local communication overhead but also trigger additional rendering and layout calculations inside the browser. Jev compresses "read the interactive element list once" into a single batched call and skips screenshot capture and off-viewport content fetching, reducing CDP round trips at the source. This is why even when model inference time doesn't meaningfully change, overall end-to-end latency still drops by about 25% — the bottleneck isn't only in the model; it's also in the round trips between the browser and the Agent.

Pre-execution Verification: No Acting on Stale Answers

What if the page changes right after the model makes its selection? Jev won't blindly execute based on outdated information. Before actually carrying out an action, it checks once more: is this still the same page? Is the target element still present? Is the button blocked by a popup? If anything doesn't match, it discards the planned action and re-reads the page.

It supports these action types: click, type, select, scroll, wait, and finish. Once running, a local inspection page opens where you can see which elements were detected, what action is planned, which target was selected, and what steps have been taken so far — making it easy to debug and observe the decision chain.

Open Source Doesn't Mean Free: Costs and Dependencies

Although the code is open source (MIT license), running it fully isn't free. GIV, the core model responsible for deciding "what to click or select next," currently only works through TypeSafe's official API. When text input is needed, the project also calls a text model — the default configuration uses OpenRouter, which requires an additional API key.

The text model can be replaced with a local OpenAI-compatible service, but GIV — the model handling click decisions — currently only operates via remote API. This means you can run text generation locally, but the Agent cannot run entirely offline.

TypeSafe currently charges by input volume at $0.042 per million tokens, with output being free. The official documentation doesn't list a permanent free tier; whether registration comes with any credits depends on the account page at the time of sign-up, so it shouldn't be treated as a free solution. The team has cited a very low per-run cost figure, but that number only accounts for two text generation calls and doesn't include TypeSafe billing — it cannot be used as the total cost for a complete flight search session.

TypeSafe is a proprietary multimodal structured-output service developed by the team behind Jev, and GIV is its core model, optimized specifically for tasks like "given a list of action candidates, output a structured action." Unlike general-purpose large language models, GIV's output is constrained to a fixed format defined by a JSON Schema (one of TypeSafe's core selling points), eliminating the need for the model to generate free-form text that then gets parsed — this reduces output tokens and lowers parsing error rates. TypeSafe's current pricing structure (input tokens charged, output free) means the longer the element list and the more steps involved, the higher the cost. However, since Jev already filters elements, per-step input token counts are relatively contained. The real thing to watch: as task step counts increase or pages contain more elements, cumulative costs grow linearly. Don't use the official two-step demo cost to estimate the price of complex tasks.

It's Picky About Pages and Tasks

Jev is fairly selective about page types. Standard buttons, input fields, and dropdowns are handled reliably; but Shadow DOM, iframes, Canvas, file uploads, new tab navigation, nested scrolling, or complex keyboard interactions may cause it to stall midway.

It also uses your existing Chrome profile. If you're already logged into accounts in your browser, be careful about which sites and account permissions you expose during testing. Payment flows, data deletion, and message sending are actions you should not let it execute autonomously end-to-end.

Given these characteristics, appropriate use cases include: researching information, filling out standard forms, and toggling a few filter options — short, low-stakes workflows. For anything involving file uploads, cross-frame navigation, CAPTCHA solving, or sensitive account access, add manual confirmation steps rather than trusting it to run unattended.

Summary

Jev Ultrafast's core idea is straightforward: compress a web page into an action checklist, then have the model make selections from it. Less to read, fewer browser calls — that's why it's fast. As of September 22, 2026, the project has 15,975 stars and is licensed under MIT. One important caveat: the speed and cost figures in this article all come from the repository's public demos and reports, not independent reproduction. It genuinely is fast — but its applicable scope and real-world costs need to be evaluated against your own use case.