ego lite Gives Every Agent Its Own Browser Space, and Hands Each One Your Logins

A macOS Chromium build where you and your coding agents share one browser without fighting over tabs. The speed claim holds up for a reason worth stealing. The isolation claim means less than it sounds like.

The ego lite repository is MIT licensed and does not contain a browser.

Thirty-four commits, JavaScript and TypeScript, a skill folder, a spec folder, a Claude plugin manifest, and a README that points you at a .dmg hosted on a CDN. The license text is explicit about it: "The ego lite browser is a separate, free download." What's on GitHub is the connective tissue. The Chromium build doing the actual work is closed.

That's a strange shape for a project climbing a trending board, and it's the second most interesting thing about the project. The first is the idea it's built on, which I think is correct and which almost nobody else has shipped: your agent should not be driving your browser. It should be driving its own, inside your browser, with your session.

The problem it names is real, and the current answers are both bad

If you've run a browser automation task from a coding agent, you know the two available shapes and you know they both cost you something.

Libraries like browser-use and Vercel's agent-browser are frameworks the agent calls. They ship no browser, so they drive a separate one, which means your logins never carry cleanly. You end up either scripting a login flow with credentials in a config file or copying cookies around. And when the agent does take a browser, it takes your browser. Your cursor moves. Your tabs change under you.

The AI browsers, ChatGPT Atlas and Perplexity Comet, solve the login problem by being the browser you already live in. They solve it by shipping one built-in agent that is the only thing allowed to drive. Your Claude Code session doesn't get a turn.

ego lite is the third answer: one browser, designed from the start for a human and any external agent to share, with the agent getting isolated workspaces called Spaces. You browse in front. Agents work in the back. You can see which Space has an agent running, take it over, or stop it. The README's example is Claude Code enriching ten leads in ten parallel Spaces while Codex scrapes five competitor sites in five more, and your mouse stays where you left it.

That's the right decomposition of the problem. Whether this particular implementation survives contact with the market is a separate question.

The speed comes from code, not from the browser

Here's the mechanism, and it's the part I'd steal even if I never installed the app.

ego-browser is the layer between an agent CLI and the browser. It exposes the browser as in-page JavaScript functions: snapshot, fill, click, wait, navigate, capture. The agent doesn't call those one at a time through a tool protocol. It writes a JavaScript snippet that calls them in sequence, and ego-browser runs the whole snippet on the page in one pass.

Compare that with the conventional loop. Call a tool. Wait. Read the result into context. Decide. Call two more tools. Wait. Read. Every step is a round trip, every result is tokens, and on a long form the model gets more chances to lose the thread between step four and step nine.

The difference is radio-controlling a car one turn at a time versus handing it the route. On a short trip you won't notice. On a twelve-turn route through a checkout flow, one is obviously better.

CitroLabs benchmarked ego lite against Vercel's agent-browser on four complex automation tasks and reports each finishing up to 2.5× faster with substantially fewer tokens, with the gap widening as tasks get harder. I believe the direction. The multiplier I'd hold loosely, and I'll say why in the limitations section.

The other technical claim is snapshot quality. Snapshots are the text view a model uses to "see" a page, and ego lite says kernel-level customization of the browser lets it handle deeply nested iframes where other approaches break. Nested iframes genuinely are where page-reading falls apart, so the claim is aimed at a real pain. It's also a claim about code you cannot read.

The isolation is ergonomic, not a security boundary

On first launch, ego lite asks one question: do you want to migrate your Chrome data. Say yes and, in the README's own words, your agent inherits your existing logins, cookies, extensions, and bookmarks.

Read that next to the Spaces feature and the shape becomes clear. Spaces isolate agents from each other and from your open tabs. They do not isolate an agent from your authority. An agent in its own Space, holding your session cookies, can do anything you can do on every site you're signed into. The separation is about your cursor, not your account.

I want to be fair to the project here: that's the entire product thesis, stated plainly in the README, and it's why the thing is useful at all. "No login friction" is a feature row in their own comparison table. Nobody is hiding it.

But the word "isolated" is going to do work in people's heads that the implementation does not do in practice. An isolated Space sounds like a sandbox. It's a workspace. Your browsing data staying on your device is a privacy property, and a good one. It is not a permissions property. Whatever approval gate you get comes from your agent CLI, not from ego lite.

Put this into practice

The install is about five minutes. The careful version is about twenty, and I'd do the careful version.

Download the build for your Mac from the README's Apple Silicon or Intel link. macOS only today. Windows and Linux are listed on the roadmap. Double-click to install. This also installs the ego-browser helper and writes the skill into every agent CLI on your machine, which is convenient and worth knowing about before it happens.
Say no to Chrome migration on the first launch. You can always migrate later. Start with an empty profile so your first few runs cannot touch a real account.
Read skills/ego-browser in the repo before you run anything. It's the actual contract between your agent and the browser, it's short, and it tells you what the model is allowed to do on a page.
Run one trivial task. In your agent CLI, type /ego-browser and describe what you want in plain language. The README's own starter is following an account on X. Watch which Space it opens in and confirm your own tabs stay put.
Ask the agent to print the JavaScript snippet before executing it, at least for the first few authenticated runs. The single-pass execution model is where the speed comes from and it's also the thing that runs without you seeing it. Look at one.
Only then decide about your Chrome data. If you do migrate, consider building a separate Chrome profile first that holds only the logins the agent actually needs, and migrating that.

Step five is the one people will skip. Don't.

Honest limitations

macOS only. If you're on Windows or Linux, this is a roadmap item, not a tool.

The browser is closed source and the repo is not the product. MIT covers the skill, the spec, and the helper. It does not cover the Chromium build you install from a CDN, and the kernel-level snapshot claim sits entirely inside code you can't audit. For a tool whose pitch is "give me your logged-in browser state," that's a real ask.

The trending placement and the repository disagree. When I loaded the GitHub page during this write-up it served 47 stars, 0 forks, 0 watchers, 34 commits, and a single release tagged "latest" dated June 1, 2026. A third-party skill aggregator listed the same project at 1.2k stars the same day. Momentum boards measure attention, and attention on browser-agent projects is currently enormous. Neither number is adoption.

The benchmark is a chart, not a methodology. Four tasks, one competitor, a PNG in the repo, no harness published, run by the vendor. "Up to 2.5×" is the best of four results. The architectural argument for why code-mode beats a tool-call loop is sound on its own, which is the part I'd act on.

One headline feature is unbuilt. "Experience accumulation," the claim that distilling successful actions into reusable tools makes similar tasks up to 5x faster, is marked coming soon in the same feature table as the shipped items. It's a roadmap entry formatted like a capability.

The comparison table is scored by the team that wrote it. Every row is theirs, including the ones where competitors get a dash.

Zero forks and one release. This is a very young project asking for a high-trust position on your machine, in a week when a single ChatGPT link was shown to be enough to build a rogue agent out of connectors somebody had already authorized. That timing isn't ego lite's fault. It's still the context you're deciding in.

What I'd actually watch

Forget the AI-browser race for a second. The claim worth testing is the small one: that letting an agent write a program against your tools beats making it hold a conversation with them.

If that holds up under someone else's benchmark, it generalizes way past browsers, and every MCP server exposing twelve granular tools is leaving the same latency and token budget on the table that agent-browser is. Run it yourself on a task you can time. That's a more interesting afternoon than arguing about star counts.

Sources: citrolabs/ego-lite on GitHub, README and repository metadata read live; lite.ego.app documentation and roadmap.