Agent and MCP guides · 2026-09-17
What is Jev? TypeSafe's choice-based decision model for browser agents
TypeSafe's Jev model produces structured decisions such as choices, scores and truthfulness ratings instead of free text. Read how jev-ultrafast applies this to browser agents, the speed difference measured in its own docs, and where the architecture's limits are.
What are Jev and TypeSafe?
Jev is the flagship member of what TypeSafe calls its "System One" model family. Its job is not free text generation; it makes structured decisions: choosing from a list (Choice), scoring a state against a rubric (Score), or rating how true a statement is on a 0-to-1 scale (Noul). The company's own landing page sums this up as "Ask Jev, up to a million times."
The point of the design is parallelism: every question in one request is evaluated against the same state, independently and at once. According to TypeSafe's documentation, adding a question barely affects response time, because questions are processed in isolation and in parallel. The recommended design philosophy is to split a complex decision into small, well-scoped questions rather than one large one, and combine the results in code.
The usual slowness of browser agents
A common agent architecture takes a screenshot, sends it to a vision model, has the model answer in free text such as "click this coordinate," and has code parse and execute that text. Every step of that loop carries the cost of image processing, free-text generation and parsing; as step count grows, the number of low-level protocol calls made to the browser grows with it.
In jev-ultrafast's own measurement, this older approach needed a median of 1,092 browser protocol calls to complete the same task. The problem is not one slow step; it is the fixed cost each step carries, added up.
jev-ultrafast: separating the decision from the text
jev-ultrafast is an MIT-licensed open-source demo published jointly by Browser Use and TypeSafe. Every page observation produces an indexed table of visible controls (buttons, comboboxes, text fields). One Jev request asks which operation to perform (CLICK, TYPE_TEXT, SELECT, SCROLL_UP, SCROLL_DOWN, WAIT, DONE, BLOCKED) and, at the same time, a candidate target for every operation that is currently valid; the executor only consumes the target answer for the operation that was actually chosen.
So the operation and target decisions happen in one network round trip instead of two serial calls. An actual text-generating language model only gets involved when TYPE_TEXT is chosen, and only to produce the value for that one field; it never decides the operation or the target. The browser connection itself runs through a separate open-source component, Browser Harness.
The speed difference measured in the source project
The table below comes from jev-ultrafast's own measurement file; it has not been independently reproduced by LLMTR. The source itself states plainly that this is not a general reliability benchmark, but a few repeats of one task on one browser profile.
| Measurement | Value | Note |
|---|---|---|
| Zurich → London, Google Flights | 7.1 seconds (7,073 ms) | Starts after the first page observation; includes model calls, generated text and loading waits |
| Median task time, six alternating runs | 9.450 s → 7.092 s (25% reduction) | Same task, same browser profile, same models and settings |
| Median browser protocol calls | 1,092 → 101 | Same six runs; both versions passed 3/3 |
| Opening a Wikipedia article | 2.798 s | Separate, single-task measurement, same decision policy |
| Local hotel search/filter task | 1.896 s | Separate, single-task measurement, same decision policy |
Limits and the need for independent verification
A DONE choice is not proof that the task actually succeeded; even the source's own guidance recommends an independent verification step. Coverage is limited too: shadow DOM, iframes, canvas, file uploads, pop-ups and nested scrolling are explicitly left out of this first version.
Working on two example sites (Google Flights, Wikipedia) is not proof of general reliability, and the source says as much: the policy is generic, but two websites do not establish broad reliability. A valid operation choice can still be the wrong one.
Why this architecture is being talked about now
AI agents that can control a browser are spreading quickly across different providers and open-source projects, and they all share the same trade-off: how much image processing and free-text generation each step needs, and what that costs in latency and money. jev-ultrafast answers that trade-off concretely by reducing decision-making to a choice and compressing free-text generation into the one moment it is actually needed — the value written into a field.
That separation has a practical consequence too: the text-generation step becomes an ordinary OpenAI-compatible request, independent of the decision engine. That makes it portable to architectures where a different system makes the decisions.
Where LLMTR fits in this architecture
Jev's decision API belongs to TypeSafe and is a closed service; LLMTR does not replace it, and this article makes no such claim. But the small language model called on the TYPE_TEXT operation is a standard OpenAI-compatible chat completions request — exactly the endpoint shape LLMTR serves.
Without touching the decision engine, it is possible to run just that narrow text-generation step through LLMTR. The environment variable changes, the actual request shape, and what to watch for are covered step by step in this series' integration guide.
Frequently asked questions
What is Jev?
Jev is the flagship member of TypeSafe's "System One" model family. It produces structured decisions — choices, scores, and truthfulness ratings — instead of free text, evaluating every question in a request in parallel and in isolation.
Is jev-ultrafast an LLMTR product?
No. jev-ultrafast is an MIT-licensed open-source demo owned by Browser Use and TypeSafe. LLMTR does not own or operate this project; this article only examines its architecture and where it intersects with LLMTR.
Did LLMTR run the speed measurements in this article?
No. The figures come from jev-ultrafast's own measurement file, and the source itself states this is not a general reliability benchmark. LLMTR has not independently reproduced these measurements.
Can I call Jev's decision API through LLMTR?
No. Jev's choice and scoring API is a closed service owned by TypeSafe, and LLMTR does not offer it. LLMTR fits a separate component in this architecture: the text-generation step (TYPE_TEXT).
Do I need jev-ultrafast to use this architecture?
No. Splitting decisions into a structured choice API and text generation into a separate, narrow LLM call is not specific to jev-ultrafast; you can build the same separation into your own agent and point the text-generation step at LLMTR.