jev-ultrafast Tested: AI Searches Flights in 7 Seconds, But Crashes on 12306

The BrowserUse team's new tool jev-ultrafast (pronounced "Jeff Ultrafast" in the demo video) pushes browser automation Agent speed to a new level. According to hands-on testing by Bilibili creator Tianji, given a goal — such as searching for flight tickets — the entire process from input to result takes just 7 seconds. The creator emphasized this was raw, 1x-speed screen recording with no time-lapse involved.

Where the Speed Gains Come From

jev-ultrafast has a clear purpose: accelerating browser Agents. It doesn't require manual step-by-step breakdown — just give it a goal, and it selects actions, plans a path, and completes the task in one fluid sequence.

Official benchmark data shows real, measurable improvements: for the same booking task, the original BrowserUse had a median runtime of 9.45 seconds, while jev-ultrafast clocked in at just 7.09 seconds — roughly 25% faster. The more striking metric is at the infrastructure level: browser protocol calls dropped from 1,092 down to 101, nearly a tenfold reduction. That means far less round-trip communication overhead, which is the core reason for the speed boost.

Browser protocol call count is a key efficiency metric in browser automation. Modern frameworks like Playwright and Puppeteer communicate with the browser via the Chrome DevTools Protocol (CDP) — every click, screenshot, DOM query, and text input is a protocol call. More calls mean more round-trips between the Agent and the browser, and the accumulated network latency and serialization overhead directly translates to longer total runtime. Reducing calls from 1,092 to 101 is achieved through smarter batching, eliminating redundant page-state queries, and more precise one-shot element targeting — avoiding the inefficient pattern where traditional Agents "re-check the scene after every single step."

Not a Black Box: The Visual Inspector

One of the biggest pain points with automation Agents is the opacity of their decision-making — when something goes wrong, debugging is a nightmare. jev-ultrafast addresses this with a built-in visual Inspector tool.

It assigns a number to each element on the page and clearly displays which element was selected at each step along with the corresponding confidence score. This transparent approach dramatically lowers both debugging costs and the trust barrier. For developers building automated workflows, being able to see the reasoning behind every Agent decision — rather than facing a black box that only shows results — makes a meaningful difference.

Open Source Friendly, No Model Lock-in

The project launched on GitHub only 11 days ago and is gaining stars quickly. It's licensed under MIT, making it very commercial-friendly and lowering the adoption barrier for both businesses and individual developers.

On the model side, it remains open and doesn't lock you into any specific vendor. Any model with a compatible standard interface can be plugged in, including domestic Chinese models like GLM and DeepSeek^Ad. For Chinese developers, this means the entire automation pipeline can be driven by lower-cost, more compliant models.

Crashes on 12306: Complex Pages Remain a Weakness

The speed and transparency are impressive, but jev-ultrafast is not a silver bullet. Community testing on 12306 (China's national rail booking platform) hit a significant wall.

According to findings shared by Tianji from the community, when tasked with searching for trains from "Beijing to Yunyang," the Agent ran into serious trouble. 12306's city suggestion dropdown is implemented with plain <div> elements, which the Agent simply couldn't "see." It fell into an infinite loop — repeating the input of "Beijing" 60 consecutive times — and ultimately failed after 77 seconds, exceeding its budget without completing the query.

This case exposes a common challenge for browser Agents: when faced with non-standard pages that rely on dynamic rendering or custom interaction patterns, element recognition still falls short. A fix PR has already been submitted but hasn't been merged yet, so the issue remains unresolved.

The root cause lies in how browser Agents perceive pages. Most Agents "understand" a page through screenshots or DOM tree parsing — but dynamically rendered custom components (like a city autocomplete dropdown built from plain <div> tags) typically lack semantic markup (<select>, role="listbox", etc.). The Agent's element recognition model can't map them to interactive controls. 12306's city suggestion list is exactly this case: it looks like a dropdown visually, but has no standard form control semantics underneath. The Agent can't detect when it appears and therefore can't trigger a selection — so it just repeats the previous step, creating a loop. These "visually visible but semantically unreachable" elements are a universal blind spot for all LLM-based browser Agents, not a flaw unique to jev-ultrafast.

Who Should Use It — and Who Shouldn't Yet

Overall, jev-ultrafast has a fairly well-defined target audience.

If you're a developer looking to speed up browser Agents and build automated workflows, it's worth trying — fast execution, transparent decision-making, free model choice, and commercial-friendly licensing all check out.

But if you're hoping to use it as a universal "macro bot" that reliably handles complex operations on any website, it's not there yet. Complex domestic Chinese sites like 12306, which rely on custom Div-based components, will still trip it up. Think of it less as an out-of-the-box universal solution and more as a fast-maturing specialized tool.

The project is called jev-ultrafast and is searchable on GitHub. For anyone tracking browser automation and AI Agent performance, it's worth keeping an eye on future iterations and incoming PR merges.