Jev Ultrafast is a browser agent that uses Jev to choose actions and an independent language model to write in text fields.
That division becomes more interesting when you follow an action from observation to execution. The application builds the available options, links them to actual page elements, and checks whether a decision is still valid before acting.
For those developing browser automation, it’s worth examining that code. Model latency is only part of the time an agent needs to complete a task.
This article analyzes the code and documentation published on September 22, 2026. We have not run the project or independently reproduced its measurements.
What’s the difference between Jev and Jev Ultrafast?
Jev is TypeSafe’s decision model; Jev Ultrafast is a browser application built on top of it.
Jev evaluates the state of an application and returns structured options, scores, or probabilities. The browser application provides that state and converts selected options into interactions. Our guide to TypeSafe’s Jev explains the model and its more general uses.
Here we’re interested in understanding how the application converts a changing page into something a decision model can handle. TypeSafe Documentation
How does Jev Ultrafast work when choosing browser actions?
The agent builds an indexed table of observed controls and groups valid targets by operation.
A text field can receive writing. A button can receive a click. A supported dropdown exposes the observed options. The available options change when the page changes.
The model receives the URL, title, visible text, the element table, and the history of recent actions. It selects based on that representation.
That’s why the observation layer matters: a missing or poorly described control changes what the model can choose. Faster prediction doesn’t compensate for a page representation that omits the necessary action. Action space implementation
How does it choose an operation and element in a single request?
The application sends the question about the operation together with separate questions about the corresponding element for each supported interaction type.
Conceptually, it asks what operation should be performed next, which element it would click on, and which field would receive text.
It only uses the response about the element that corresponds to the selected operation. Choosing a click doesn’t also execute the proposed write action.
This organization avoids a second round-trip communication with the service to select the element after choosing the operation. The application validates the selected responses against the options it provided. Decision implementation
When does it use a language model to write text?
The auxiliary text model intervenes when the chosen action needs a value for a field.
Jev decides where to write. The auxiliary model receives the target, the selected field, the page context, and recent actions to produce the text. In the documented flight example, city names are generated this way.
The loop checks that the page is still current before requesting the text and again before entering it. If a page change interrupts execution and forces a retry, a generated value can only be reused when the entire input context of the auxiliary model remains identical.
That condition matters: text prepared for a particular field or page state shouldn’t silently be moved to another context. Agent loop
What happens if the page changes before clicking?
The executor checks the observed state and calculates the current position of the element before interacting.
For clicks and selections, the checks examine the document and state related to the element. Execution also verifies that it still exists, is enabled and visible, and isn’t covered by another element.
These checks address a common browser automation problem: a decision may refer to a page that has already changed. An overlay window might appear, a control might be replaced, or a form might be updated while the model request is in progress.
The implementation also carefully handles an interrupted selection in a dropdown. If it can’t confirm execution, it stops for inspection rather than assuming that repeating the action is harmless. Browser executor
The loop consumes the pending decision before attempting to execute it and logs the executed action before observing again. These design decisions help prevent a retry from repeating an already-consumed decision or losing the record of an action if the next observation fails. Agent loop
Where does Jev Ultrafast’s speed improvement come from?
The project’s comparison attributes the improvement to changes in the browser execution code, while maintaining the same models.
Both versions used Jev and Mercury. In three test pairs, the median task time dropped from 9,450 to 7,092 seconds, a 25% reduction. The median browser protocol calls went from 1,092 to 101.
The report describes several changes: reading controls together, avoiding invalidating decisions for each irrelevant DOM modification, and briefly waiting for autocomplete suggestions to appear before requesting another decision.
These are results published by the author for one task and browser profile. They justify examining the design of the execution code; they don’t establish a general speed advantage over other agents.
The recorded demonstration of 7,073 seconds searched for flights. It did not make a booking. The measurement excludes browser setup, initial navigation, and subsequent independent verification. The reported cost for the text model helper also does not include other task costs. Performance Methodology
How to Install Jev Ultrafast to Inspect It Locally?
The repository documents a local inspector to observe the decisions and actions executed.
These are its installation instructions:
git clone https://github.com/browser-use/jev-ultrafast.git
cd jev-ultrafast
uv sync
cp .env.example .env
Add the documented credentials TYPESAFE_API_KEY and TEXT_MODEL_API_KEY to .env and run:
uv run jev
Open http://127.0.0.1:8766. The inspector displays numbered elements, operation probabilities, target element probabilities, and executed actions. Choose next allows you to stop before execution.
As of September 22, 2026, the example configuration uses an OpenRouter key for the text model helper. Follow the current repository configuration when testing it; examples with real services make paid API calls. Installation Documentation
What Tasks Should You Evaluate First with Jev Ultrafast?
Start with bounded tasks that use supported controls and whose results you can verify independently.
Opening a specific page or applying known filters provides a concrete result to verify. The model selecting DONE does not demonstrate that the task has been completed correctly.
As of September 22, 2026, documented limitations include frames, shadow roots, canvas, file uploads, popup tabs, scrolling within nested containers, and arbitrary keyboard controls. Tabs also share the connected Chrome profile. Use a dedicated profile without sensitive sessions during evaluation. Project Limitations
Typed decisions also do not eliminate the risk of deceptive content from a page. TypeSafe documents susceptibility to adversarial inputs in its current Jev limitations. Authorization and result verification remain the responsibility of mechanisms external to the model. TypeSafe Limitations
For teams in Iberoamerica, a useful evaluation would measure the complete task time from your deployment region, record failures and retries, and account for both model services.
The reusable lesson is in the distribution of responsibilities: the model selects from observed possibilities; the application defines those possibilities, verifies execution conditions, and validates the result. Jev Ultrafast provides a compact implementation for study and a starting point to check whether that design improves your own workflow.