jev-browser-use: splitting a browser agent into a cheap clicker and an expensive checker

Two models, one loop, and a deliberate division of labour

The whole design is one sentence in the README: Jev clicks, Codex thinks and verifies.

The mechanism is described in the How it works section as a loop. Goal, observe controls, Jev chooses an action, browser, repeat, Codex verifies.

What makes it work is the input format. Jev receives accessibility text, not screenshots. That is the crux of the design, because accessibility text is far cheaper to send and far cheaper to reason about than a rendered image, and it is exactly the information a click needs. A button's role, its label and its enabled state are enough to decide whether to click it, and none of the visual interpretation is needed.

What Jev cannot do is stated just as plainly. Codex handles typing, visual interpretation, and unsupported controls. So the division is not a cost optimisation bolted onto a whole-task delegation, it is a split by capability. Anything that needs a pixel is Codex's job; anything that needs a selector is Jev's.

And the result is checked. Jev's completion signal brings Codex back for verification, and sessions retain progress across handoffs, so a long task that starts with a cheap click sequence and ends with a careful visual check does not lose its place in between. The action loop also stays inside the existing Computer Use connection, which avoids a new host-model turn for every click, and that is where most of the latency claim comes from.

Where the speedup and the cost saving come from

The README makes a quantitative claim and is careful about its scope.

The claim is roughly 5 to 10 times faster browser operations in the author's EZCollegeApp workflows, and the caption under the chart is more precise: approximately 5 to 10x is our approximate browser-operation speedup, varying by task, server-side processing is excluded, and the chart illustrates the ratio.

The cost argument is spelled out with a price table. Jev 1.13 is listed at $0.042 per million input tokens with output free, and the table then compares GPT-5.6 Terra at $2.00 input and $12.00 output, GPT-5.6 Sol at $4.00 and $20.00, and GPT-6 Astra at $10.00 and $50.00, giving input price ratios against Jev of 1x, 48x, 95x and 238x.

The arithmetic in the README puts 100,000 input tokens at $0.0042 for Jev against $0.20, $0.40 or $1.00 before output charges. The prices are dated, standard uncached API rates checked on September 18, 2026, with links to the TypeSafe and OpenAI pricing pages.

Two caveats are stated. The table compares token prices, and total workflow cost also includes Codex and depends on usage. And the speedup excludes server-side processing.

The underlying point is the same one in both tables. The expensive model was being asked to make a yes-or-no decision about a button, and the saving comes from moving those decisions to a model where output is free.

Install paths, and a skill that must be configured before it works

Installation is one command for Codex.

npx skills add wy-coliney/jev-browser-use -g -a codex -y

Then you configure your Jev API and start a new Codex task. Updating a skill installed this way is npx skills update jev-browser-use -g, and the update does not change your ~/.config/jev-browser-use/config.json or your credential file, so a new Codex task is needed to pick up the new instructions.

The configuration is where the provider decision sits. A TypeSafe key goes with provider: "typesafe" and TYPESAFE_API_KEY; an OpenRouter key goes with provider: "openrouter" and OPENROUTER_API_KEY. The README insists the keys are not interchangeable even though both providers offer Jev, and the key goes in the dotenv file named by envFile in the config.

There are three alternative routes. A native Codex plugin, installed with codex plugin marketplace add and codex plugin add, which needs a CLI with codex plugin support and a restart. A plain npx skills add for other agents, where the README notes that Claude Code browser support is coming soon and that browser execution currently requires the Codex Computer Use runtime. And a manual install, git clone followed by node scripts/install.mjs, or extracting the repository ZIP and running the same command.

The prerequisites are explicit. Node.js 22 or newer, Codex with Computer Use connected to Chrome or its in-app browser, and Jev access through TypeSafe or OpenRouter. The README also says plainly that installing this Skill does not install the browser connection, which is the piece most likely to be assumed and then missed.

There is a plugin.json at the root and a skills/ directory, which is the standard Skill layout, and an INSTALL.md at the root that the README suggests pasting to Codex so the agent can install and configure it, with an instruction to never ask for an API key in chat.

Real use, and the limits of the split

The origin story is specific and it explains the design better than a benchmark would.

The project was built while testing EZCollegeApp, the author's college application product. Reviewing an essay feature meant repeatedly opening evaluations, expanding notes, scrolling reports, and returning to the editor. Jev handles that navigation, and Codex checks whether the evaluation feedback and the inline annotations agree.

That is a narrow but honest use case. The repeated part is mechanical and the check part is judgement, and the split follows exactly that line. The README says the same split works anywhere repeated browser operations slow down your agent, and that it is for dashboards, settings, reports and browser checks, not just writing tasks.

There is also a handoff mechanism for the cases the split does not fit. When a step needs help, Codex takes over and Jev resumes afterward. That is a softer split than a hard partition, but it also means the two models can end up ping-ponging, and the README does not describe how often that happens.

The security note at the end of the README is the part to read before pointing this at anything sensitive. Browser workflows were exercised on macOS, page text goes to your selected provider, and only delegate data you authorize it to process. The instruction is to keep credentials and private page content out of it, which is a reasonable default for a tool that ships page text to a third-party API, and it is a constraint you have to enforce rather than one the tool enforces.

Editorial conclusion

jev-browser-use suits an agent workflow that spends most of its browser turns on repetitive mechanical navigation, since routing those steps to a model with free output and low input cost is where the saving comes from, and the design keeps the expensive model in the loop for typing and verification rather than delegating the whole task. It is the wrong tool if your browsing is mostly text entry with a few clicks, since the split then adds a handoff without saving anything, and it is the wrong choice unless you are prepared to hold a Jev API key and a Codex session with Computer Use connected, since the skill is useless without both. Before you adopt it, read the provider configuration reference, and note that the browser workflows were exercised on macOS and that page text goes to whichever provider you select.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wy-coliney/jev-browser-use on GitHub