Jev browser agent cuts flight search to 7 seconds

The Jev browser agent is a loop that combines Jev, a fast multiple-choice judgment model, with Claude for planning and verification. Jev answers two questions per call: what action to take, and which numbered element to act on. Claude steps in when confidence falls below a threshold, when a page blocks, or when text must be written.

What the Jev Browser Agent Actually Does

The Jev browser agent is a control loop that pairs a fast multiple-choice model with a reasoning model. Jev, built by the team at TypeSafe, takes a page state plus a question set and returns an answer from defined options with a confidence score. Claude, Anthropic assistant, does the planning, the writing, and the verification.

The split matters because the two models do different jobs. Jev cannot write a sentence or hold a conversation. It answers questions such as "is this a cookie banner?" or "which numbered element should be clicked?" and returns a probability. Claude handles goals, drafts text for input fields, and decides whether a reported completion is real.

That division is what produces the speed. Jev processes a page as structured data, not as an image, so there is no screenshot to render and no vision model to run. The transcript from Simon Scrapes' October 2026 video cites about a third of a second per decision, which is the figure to test on your own page mix rather than assume.

Jev is not a hosted browser. You still need a driver such as Playwright or Browser Use to open Chrome, read the DOM, and execute the chosen click.

How the Jev Browser Agent Loop Runs, Step by Step

The loop has a fixed shape: plan, read, classify, execute, verify. Claude turns a goal into a plan and a question set. The driver reads the page and numbers every interactive element. Jev answers two multiple-choice questions in a single call. Code executes the answer. Claude checks the result before the next iteration.

The two questions are the core of the design. The first asks for an action type: click, type, select, scroll, wait, done, or blocked. The second asks which numbered element that action applies to, with a none option when no element fits. Both answers come back with confidence values.

A threshold decides what happens next. If both confidences clear a level such as 0.7, the driver executes the action, waits for the page to settle, re-reads the DOM, and calls Jev again with the same question set against the new state. Pure code handles that execution, so the step is deterministic.

Anything below the threshold, or a blocked verdict, breaks the loop and hands control to Claude. Claude looks at the goal, the actions taken so far, and the current page, then either rewrites the question set and returns to Jev or handles the step itself.

Where Claude Fits and Where Jev Stops

Claude every part of the task that requires language. Jev picks the text input box, but it cannot write the email address that goes inside it. That text comes either from the original goal or from Claude, which makes the writing step the main reason the loop cannot be purely classified. Since Jev's launch, the split has stayed stable: Jev selects the field, Claude supplies the string.

Claude also owns the completion check. When Jev reports done, the runner does not accept it. Browser Use's own README states that a definition of done needs an independent verification check, and the transcript's build uses Claude for that job. This is the single most useful design decision in the stack, because a classifier can be confidently wrong.

The pattern that emerges is a cheap model making thousands of small calls and an expensive model making a few large ones. That is a general architecture, not a Jev-specific trick. Any workflow with many small routing decisions and a handful of reasoning steps can be split the same way.

The division of labor breaks down along three lines:

Job	Owner	Why
Picking the text input box	Jev	Routed as a choice question
Writing the email address	Claude	Requires language generation
Accepting the reported "done"	Claude	Needs an independent verification check
Deciding whether to act	Null question type	Yes or no decisions
Ranking output	Score question type	Described scale for sorting

Treat the three question types as the routing vocabulary:

1. Yes or no questions map to null, which suits decisions about whether to act.
2. Choice questions map to a pick from a list, which suits routing.
3. Score questions map to a described scale, which suits sorting output by a ranking.

Cost and Speed: What the Numbers Actually Show

The published Jev price is about 4 cents per million input tokens with free output, cited in the transcript as the basis for the speed claim. Treat that as vendor-reported pricing that can change, and verify it against current TypeSafe pricing before you commit to a cost model.

Two figures from the transcript deserve separate treatment because they have different owners. The Google Flights run completing in 7 seconds and the browser call count falling from 1,092 to 101 both come from Browser Use's own documentation of their agent, not from an independent test. Those are first-party numbers about a specific task on a specific site.

The call-count drop is the more useful of the two. A reduction from 1,092 calls to 101 on the same task is a step change in how many model round trips the job needs, and it points at a structural cause: classification replaces repeated reasoning over the same page. The 7-second timing is a single run and should be read that way.

Neither number tells you what a general browser workflow will cost. A price per million tokens and a call count only become a cost estimate once you know your own page count, retry rate, and how often the confidence threshold forces a Claude fallback. The 2025 transcript gives no independent re-test, and no 2026 follow-up measurement has been published, so the figures below are dated to the sources that produced them rather than to a controlled benchmark:

Figure	Value	Source	Status
Input token price	~4 cents per million tokens	Transcript, 2025	Vendor-reported, subject to change
Output token price	Free	Transcript, 2025	Vendor-reported, subject to change
Google Flights task time	7 seconds	Browser Use documentation, 2025	First-party, single run
Browser call count	1,092 down to 101	Browser Use documentation, 2025	First-party, same task

To turn any of this into your own cost model, work through the inputs in order:

1. Confirm the current per-million-token price against live TypeSafe pricing, since the 4-cent figure is vendor-reported.
2. Count the pages your workflow actually visits, because the call count scales with pages rather than with a single demo task.
3. Estimate your retry rate, since the 101-call figure is a best case on one site.
4. Estimate how often the confidence threshold forces a Claude fallback, because that fallback is outside the classification path that produced the call-count drop.
5. Re-measure on your own workload before treating the 7-second timing as representative.

Known Failure Modes in Fast Browser Agents

Cookie banners, iframes, file uploads, false completions, and short memory are the recurring traps. The transcript's author reports hitting all five while testing, and each required extra questions in the Jev request rather than a configuration toggle. Expect the first working build to need iteration on the question set.

Failure mode	Why it breaks	Mitigation
Cookie and preference banners	A bare goal never says accept or dismiss	A dedicated yes-or-no question, with the script enforcing accept when the answer is yes
Iframes	Driver cannot see inside the frame, so the widget never enters the numbered element list	Read the vendor's scope limits before promising a checkout flow
File uploads	Listed as out of scope by Browser Use alongside iframes	Same, plus an explicit question about the upload step
False completions	The done signal is accepted without checking the goal	A verification pass against the goal before accepting done
Short memory	Only the last five actions are visible, so a 39-step task loses its thread	Keep goals short and chain them, one goal per page or per form

Cookie and preference banners fail because nothing in a bare goal tells the agent to accept or dismiss them. A dedicated yes-or-no question works better than a general instruction: ask whether the page shows a consent banner, and let the script enforce the accept action when the answer is yes.

Iframes are a visibility problem rather than a decision problem. When the driver cannot see inside an embedded frame, a payment form or signup widget is invisible to the numbered element list, so Jev has nothing to choose from. Browser Use lists iframes and file uploads as out of scope for its agent, which is a boundary worth reading before promising a client a checkout flow.

False completions are the failure that most needs the Claude check. In one transcript example, the agent reported ten blog pages complete in 77 seconds while only one or two were genuine blog pages. A verification pass against the goal catches that; accepting the done signal does not.

Memory is the last constraint. If the agent only sees the last five actions, a 39-step task loses its thread. Keeping goals short and chaining them, one goal per page or per form, keeps the visible context aligned with what the model can actually track.

How to Build One With Claude Code

A working browser agent takes one plan and roughly five to twenty minutes of setup with Claude Code, Anthropic agentic coding tool that runs in the terminal. The full flow is a plan from Claude, page data from the driver, classification from Jev, execution in code, and verification back in Claude.

Two prerequisites do most of the work. You need an API key for Jev in your environment file, and you need the skill or prompt that tells Claude how to phrase and batch the Jev questions into one call. That batching is what keeps latency low, because every extra round trip adds delay.

Build order that avoids rework:

Who Should Use This Pattern, and Who Should Not

The pattern fits repetitive, high-volume web tasks on sites whose DOM is stable enough to number reliably. It does not fit one-off tasks, pages dominated by canvas rendering, or flows that depend on cross-origin iframes you cannot reach.

A quick comparison of the two browser layers described in the transcript:

FAQ

• What is the Jev browser agent? It is a control loop that combines Jev, a fast multiple-choice judgment model from TypeSafe, with Claude for planning, writing, and verification. Jev answers two questions per call about a numbered list of page elements, and code executes the answer.

• Is Jev a replacement for Claude? No. Jev returns options and confidence scores rather than text, so it cannot reason through a goal or write content. The two models handle different layers of the same task, with Jev absorbing the high-volume routing decisions.

• How fast can a Jev browser agent run? The transcript cites about a third of a second per click decision, and Browser Use documented a Google Flights task in 7 seconds. Both are specific to their own setups, so benchmark against your own target sites before quoting either.

• Does it handle iframes and file uploads? Generally no. Drivers such as Playwright cannot see inside embedded frames, so payment forms and signup widgets stay invisible to the element list. Browser Use lists both iframes and file uploads as out of scope for its agent.

• How do you stop it reporting a task as done when it is not? Add an independent verification step with Claude that checks the output against the original goal. A classifier can return a confident done on the wrong page, and the transcript documents exactly that failure.

Turning a Working Agent Into a Blog Post

The interesting part of this build is not the code that clicks the button. It is the reasoning behind the split: which decisions belong to a fast classifier, which belong to a slower reasoning model, and where the boundary between them has to be drawn before the agent stops looping. That judgment is what makes one agent finish a flight search in seconds and another grind through the same task for ten minutes.

That kind of reasoning usually lives in a video, where you can show a failing run, explain why the threshold was wrong, and demonstrate the fix on screen. Skala Blog turns a YouTube URL into a written article: it transcribes the video and generates a draft you can edit and publish, so a recorded walkthrough becomes something people can search for and reference later.

If you have already recorded an explanation, a build session, or a breakdown of what broke, paste the link into Skala Blog and work from the transcript instead of starting from an empty page.

Source video