Why a Decision Model Can Be Faster Than an LLM Browser Agent

A browser agent spends most of its steps on questions that already have a closed answer set. What should happen next? Which control on this page? Is the result list on screen yet? Those are Choice problems. Jev is built to return a typed choice and a probability distribution. It is a poor fit for inventing a paragraph, and a general language model is a heavy fit for picking element 7.

Jev Ultrafast is the clearest public agent that draws that line in code. This page is about the line. The file-by-file loop is the architecture guide.

Bounded decisions are the actual job

Give a model a page and ask “what JavaScript should run?” and you have handed it an open generator’s job, plus the privilege to aim that JavaScript at the wrong node. Ultrafast refuses that interface.

The program observes the page and writes down the only answers it is willing to execute:

• an operation from the set the snapshot supports
• an element index that was in this snapshot
• a select option index that was in this snapshot

Jev’s work is to pick. The browser’s work is to resolve that id back to the node it already holds. If the id is stale, covered, or missing, nothing runs. That is a decision layer: the model proposes inside a contract the executor can reject.

The same shape shows up outside browsers. Routing a ticket, keeping or dropping a retrieval hit, and picking a tool are the examples already on this hub: model routing and tool selection. Ultrafast is those patterns pointed at a DOM.

Where a language model still belongs

Ultrafast does not pretend Jev can type Zurich. TYPE_TEXT is a decision (“this field, now”). The characters are a generation problem, so a small chat model returns one JSON string. The published run used Mercury 2.5 for that and nothing else.

A useful agent stack then has four different kinds of work:

Work	Better owner	Ultrafast’s owner
Classify the next action	Decision model	Jev
Pick a known control	Decision model	Jev, same request
Write a field value from the goal	Small generator	Text helper
Long planning, ambiguous policy, or a written answer for a person	Larger language model	Not in this loop
Click, type, scroll, verify geometry	Deterministic code	Browser harness

The third-party story that “one giant model does every step” is a product default, not a requirement. Splitting the stack is how you keep control flow in your process. Official System One docs make the same point for refunds: Jev answers the judgments, and code performs the eligibility checks and the side effect. Ultrafast is that sentence applied to Chrome.

One round trip for two questions

Even a fast decision model is slow if you serialize it. After Jev says CLICK, a second request for “which element?” adds a network wait on every step. Speculative fan-out asks the independent questions together.

Ultrafast always asks for the operation, and also asks for the best click target, type target, and select target whenever those candidates exist. The extra answers are cheap relative to a second round trip because they share the request. They are also safe, because the client validates and executes only the head that matches the operation. Predicting a type target does not type.

That is the architectural reason a sub-second decision step is plausible. The Flights recording’s median Jev latency was 178 ms, across 17 requests, with two extra helper calls for the city names. The 7.073-second total still includes Google loading and a stale-decision path. Latency of the decision call is not latency of the task.

Do not promote the demo into a law

The numbers are worth knowing and easy to overread. Full tables are on the explainer. The short version:

• One verified Flights recording completed in 7.073 seconds. It searched. It did not book.
• A three-pair before/after on that same task moved the median from 9.450 s to 7.092 s. Sign-test p = 0.25.
• Wikipedia at 2.798 s and a local hotel fixture at 1.896 s are smoke checks.

Use them as evidence that this architecture can finish a scripted web task quickly, including real text generation and a loading wait. Do not use them as a leaderboard.

The decision is not the outcome

A fast Choice can be confident and wrong. Ultrafast’s own instructions say DONE needs visible evidence, and the performance note says DONE is still not independent evidence. The Flights example therefore has a checker that is not the model: route, date, and visible options, run outside the timer.

Any decision layer needs that second voice:

1. The model may stop.
2. Code checks the world.
3. If the check fails, the run is a failure even though the model said DONE.

Skipping step 2 is how an agent demo becomes a false success. The check has to look at the thing the user asked for, not at the model’s last token.

What this means for a System One stack

TypeSafe’s name for the class is System One: fast structured decisions, with the slower work left to something else. A practical split for agents:

• System One (Jev): operation, target, route, tool, filter, “is this requirement visibly met?”
• System Two (a larger LLM): the steps you cannot honestly reduce to a criteria map you wrote down
• A small generator: strings, and only strings
• Your code: effects, budgets, retries, and the outcome check

You build the criteria map. If you cannot list the legal answers, you do not have a Choice yet, and calling Jev will not create one. Ultrafast’s snapshot is that list, rebuilt every step from the live page. When the page uses a shadow root, an iframe, or a canvas the snapshot cannot see, the decision layer is blind there, and the honest operation is BLOCKED or a different reader — not a freer model output.

When this pattern is the wrong tool

• The user wants an explanation, a draft, or a plan written out. That is generation.
• The next action is not in the controls you can name. Widening the model’s output to selectors and coordinates throws away the guard.
• You need a reliability claim across sites. Ultrafast’s authors did not make one, and this page should not invent one.

Next: read the 7-second run in context, or follow the tutorial if you want the calls on the page.