Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 3, 2026 · repo

lexmount/moliagent-infrastructurelocal-aimulti-agent

Moli Matches Chrome Headless on the Open Web and Misses 18% of Chrome's Tests. Both Numbers Matter

The Rust headless browser for AI agents uses a tenth of Chrome's memory, and its own README tells you exactly where to keep Chrome around

The browser most AI agents drive was built for people.

Every agent that reads the web today mostly drives Chromium, a program designed to paint pixels for human eyes, and then throws the pixels away to read the DOM. Moli, the open-source headless browser from Lexmount that sat at number one on Trendshift on October 3, starts from the opposite assumption: an agent wants structure first and pictures almost never. Its README makes two claims that sound contradictory until you read them side by side. On a crawl of 192 public URLs, it got useful pages from 103, one more than Chrome Headless. On its larger test suite of 1,308 comparable tasks, it passed 81.88 percent. Chrome passed 99.85 percent.

Both numbers are true, both are self-reported, and together they tell you how to use it.

What moli is

Moli is a browser kernel written in Rust, not a Chromium wrapper. It runs JavaScript on V8 through rusty_v8, parses HTML with html5ever, and borrows styling and rendering pieces from the Servo and Vello projects. Version 1.1.12 shipped on September 30. It is dual-licensed MIT or Apache 2.0, and the repository had about 5.8k stars on a cache-busted read on October 3.

The design choice that matters is the default. Out of the box, moli runs with what its README calls LayoutPolicy::Mock: "deterministic geometry in a compatible format, with no real layout or paint." When an agent asks for HTML, Markdown, a DOM query, a script result, or network and storage state, moli "reads browser runtime state directly" and never lays out or paints the page. Real layout, hit-testing, coordinate clicks, screenshots and screencasts only switch on with the --layout flag, and even then a screenshot is rendered fresh from current state and discarded after.

It speaks the protocols agents already use: Chrome DevTools Protocol, WebDriver Classic and WebDriver BiDi. Playwright connects over CDP with no special client.

The numbers, read honestly

Here is what the README reports, all measured by the project itself.

On the mixed public-web crawl of 192 URLs, moli got 103 useful pages (53.6 percent) against Chrome Headless's 101 (52.6 percent), at the same median time of 1.43 seconds. Median memory was 73 MiB for moli and 773 MiB for Chrome.

On a sample agent workload, moli was ready for CDP in 34.85 ms against Chrome's 169.37 ms, and peaked at 102.46 MiB against 348.82 MiB.

On Lexbench-Headless-Browser, the README describes a corpus of 1,928 tasks covering raw CDP, 13 pinned automation tools including Playwright, Puppeteer and Selenium, and web-platform semantics. A 1,308-task comparable subset was used so a remote-only competitor could be included. On that subset, moli passed 1,071 tasks (81.88 percent) against Chrome's 99.85 percent, using about 15 percent of Chrome's median CPU time (100.6 ms against 687 ms) and about 13 percent of its median peak memory (92 MiB against 697 MiB).

My read: the crawl number says moli handles the pages agents mostly visit as well as Chrome does. The Lexbench number says roughly one automation task in five that works in Chrome does not work in moli yet. Those do not contradict each other. Reading content is the easy part of a browser. Driving it through every corner of an automation API is the hard part, and that is where the gap lives.

So the position this article takes is narrow. Moli is a strong default for the read-heavy half of agent browsing and a risky replacement for the interaction-heavy half. If you run dozens of browser sessions per agent host, a tenfold memory cut is the difference between one machine and several. If your agent fills multi-step forms on JavaScript-heavy apps, the 18 percent gap will find you.

The design detail that makes a fallback easy

One sentence in the README matters more than any benchmark: "Unsupported protocol paths return explicit errors. Moli never pretends that a browser action, event, network observation, or visual result occurred."

That is the property you need to build a two-browser setup. A browser that silently returns an empty result or a fake success is impossible to route around, because your agent cannot tell a real empty page from a missing feature. A browser that fails loudly can sit in front of Chrome as a fast first try.

Put this into practice

Start with the read path, where moli is strongest and the risk is lowest.

1. Install and fetch one page as Markdown.

curl --proto '=https' --tlsv1.2 -fsSL \
  https://github.com/lexmount/moli/releases/latest/download/moli-installer.sh | sh

moli fetch --dump markdown --wait-until done https://example.com

Read the install script before you pipe it to a shell, as with any curl-to-sh installer.

2. Run it as a CDP server and point Playwright at it.

moli serve            # CDP on port 9222 by default

import { chromium } from "playwright";

const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();
await page.goto("https://example.com");
console.log(await page.locator("body").innerText());
await browser.close();

Because the client is plain Playwright, your existing extraction code should run against it unchanged for basic reads.

3. Add a fallback, not a migration. Wrap your browser calls so that an explicit moli error, an empty extraction, or a timeout retries the same step in Chrome Headless. Log every fallback with the URL and the failing call. After a week you will have your own version of the Lexbench gap, measured on your sites instead of the project's.

4. Turn on --layout only where you need coordinates. If your agent clicks by pixel position or needs screenshots for a vision model, start that session with moli serve --layout. Leave read-only sessions in the default mock mode, where the memory savings come from.

Honest limitations

Every number in this article comes from moli's own README. Lexbench appears to be the project's own suite, and I found no independent benchmark of moli against Chrome. Treat the figures as the vendor's best case until someone else reproduces them.

The default mock geometry is a trap for the unwary. Code that reads element positions or clicks by coordinate will get deterministic but not real geometry unless you pass --layout. If an agent's clicks land in the wrong place, check that flag first.

The README is explicit about what moli does not attempt: no GPU compositor, no retained multi-frame paint, no pixel-for-pixel Chrome parity, limited fidelity for canvas, WebGL and media playback, and not every Chrome screenshot or print mode. Sites built on canvas apps or heavy media will need Chrome.

The README says nothing about anti-bot detection or captchas, so do not assume a new browser engine will pass checks tuned for Chromium. Plan for the fallback to carry that traffic.

Moli also has a commercial sibling. Lexmount sells a managed cloud runtime, Lexmount Browser, built around the kernel, though the README states the open-source browser is "fully usable without" it. The license is permissive either way, but the roadmap will follow the company's priorities.

Where this leaves you

Agent browsing has been stuck paying for a renderer it mostly ignores. Moli is a credible attempt to stop paying, and its README is unusually candid about the cost: parity on reading, a real gap on automation, and loud errors where it falls short.

That candor is the reason to try it. Put moli in front of Chrome for one read-heavy agent this week, log the fallbacks, and let your own traffic decide how much of Chrome you still need.

Sources: lexmount/moli README, moli releases, Trendshift daily board.

Medium metadata

  • Title: Moli Matches Chrome Headless on the Open Web and Misses 18% of Chrome's Tests. Both Numbers Matter
  • Subtitle: The Rust headless browser for AI agents uses a tenth of Chrome's memory, and its own README tells you exactly where to keep Chrome around
  • Tags: AI Agents, Web Scraping, Rust, Open Source, Browser Automation
  • Canonical: fervorai.dev URL once published