How Jev drives a browser

Jev picks, it never writes. Every step is a multiple-choice question the code builds from the live page; Jev answers with one option and a probability.

Step through a real run: the page, what the code built, what Jev answered. The logic here is scripts/core.mjs — the same file the skill runs.

page the live page

code what it built from the page

element table
also in the request
the request, verbatim

Jev what it answered

the answers, verbatim

What to notice

Each place this implementation stops is a lesson about Jev.

One request, several questions

The request asks for the operation and, speculatively, a target under every operation. The answer to the head that matches the chosen operation is used; the rest are discarded. Two dependent decisions, one round trip.

Jev only sees the table

Not the DOM, not a screenshot. Whatever the observe step failed to capture, Jev cannot choose. Early on the login fields were labelled acct and pw, and Jev answered BLOCKED 0.31. Better labels fixed it.

Jev never writes text

text_values are supplied by the caller; Jev picks which one belongs in a field. A secret is typed only into password fields and never enters a request: Jev sees the field exists and whether it is filled.

Every answer is validated

An answer is a key into a table the code built. If it is not in the offered set, the code throws and nothing runs. Model output never becomes a selector, a coordinate or JavaScript.

255 options per question

So this skill offers the first 250 controls and warns when it skipped some. The Hacker News front page has 227. Larger pages need a first question that narrows to a region before this one.

Stateless, and cheap

Every step is an independent request. The only memory is the recent_actions the code chooses to send. A step is a few thousand input tokens; output is free.

Reference implementation, MIT. Read the code on GitHub. Jev is by TypeSafe.