Show and tell: driving ego-browser with Jev (TypeSafe System One) - plus 4 runtime facts we had to measure

[jiangkoumo]

I built an add-on that replaces the per-step LLM round trip in browser automation with TypeSafe's System One model Jev: the driver sends one indexed element table and gets back an operation + target element in a single request, so a multi-step task runs inside one ego-browser nodejs process instead of returning to a large model at every step. Code keeps observation, execution, verification and exit conditions.

• Repo: https://github.com/jiangkoumo/ego-jev
• Install: npx skills add jiangkoumo/ego-jev

It is unofficial and unaffiliated. It drives ego-browser through the documented API only, and it deliberately does not touch the app bundle (an earlier version patched SKILL.md inside the signed bundle — that was a mistake, ego lite upgrades replace that directory).

Measured on macOS, ego lite 0.5.0.32, jev-1.13 — same task, same element table, same verifier, 3 alternating pairs, median:

task	Jev, single process	per-step large-model loop
two-step navigation (news.ycombinator.com)	4.9s	9.7s
Wikipedia search (both arms generate text)	5.4s	10.1s

The saving is the decision round trip (Jev ~1.0–1.5s vs the large models available to me at 1.6–4.5s) plus not leaving the browser context each step; the browser calls themselves are the same on both sides. Sample size is 3 pairs per task with high variance, so treat this as an order-of-magnitude observation, not a benchmark — the harness is in the repo if anyone wants to re-run it.

Four runtime facts that cost me the most debugging time (all reproduced with ego-browser nodejs; I opened a docs PR for these):

• a static import of a built-in — import { createServer } from "node:http" — produces no output and exits 0, so the whole script looks like a no-op; await import("node:...") works;
• custom environment variables are not passed through, so configuration exported in the calling shell never reaches the script;
• process.cwd() is /, so relative paths do not resolve the way they do in a shell script;
• loopback is unreachable: server.listen() never fires its callback, and fetch("http://127.0.0.1:…") hangs until the process exits. External HTTPS fetch() is fine — local servers have to run outside the runtime.

Two smaller ones, in case they help someone else: element loc values can contain ] (so attribute parsing has to run from the first [ to the last ], or input[name="a"] gets truncated), and checkbox/radio state is not in the snapshot (one batched page.evaluate() can read it, but if the DOM and snapshot counts disagree it is better to report "unknown" than to guess).

Happy to upstream any of this if it is useful — the docs PR is open against 2.0.0-beta-dev.

[jiangkoumo]

Small follow-up: the docs patch for the four runtime facts above is ready on a branch — jiangkoumo:docs/embedded-runtime-environment, docs-only, +17/−1 in skills/ego-browser/SKILL.md.

I could not open the pull request myself. CreatePullRequest returns FORBIDDEN for my account on this repository — against both 2.0.0-beta-dev and main — while creating this Discussion worked, and the same token creates pull requests normally in my own repositories. The compare view renders correctly and the branch is one commit ahead, so it looks like a new-contributor restriction on the repository rather than anything about the branch.

If it is useful, anyone with write access can open it from here:

https://github.com/citrolabs/ego-lite/compare/2.0.0-beta-dev...jiangkoumo:docs/embedded-runtime-environment?expand=1

Happy to reword it, split it, or drop it if you would rather document these somewhere else.

[walidmahade]

hello hello, i was looking for this. Can i start using it locally now?

[jiangkoumo]

可以，可以看看我的项目 Mahade Walid ***@***.***> 于2026年9月20日周日 23:10写道：

…

hello hello, i was looking for this. Can i start using it locally now? — Reply to this email directly, view it on GitHub <#410?email_source=notifications&email_token=BEIQMHJBZRPKECG3OYAGZXL5P7XPXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBVGI4DOMJZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18528719>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEIQMHJ6DXTFNVQVT4F2TRT5P7XPXAVCNFSNUABJKJSXA33TNF2G64TZHMYTEMJSGUYDGMRVGA5UI2LTMN2XG43JN5XDWMJQHA2DMMJRGGQXMAQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>