Moli: Rust Headless Browser for AI Agents (2026 Guide)

A headless browser usually means “Chrome without a window”. Moli makes a different bet: a standalone browser kernel in Rust that hands an AI agent the page as Markdown or JSON, and only paints pixels when you ask for them.

I read the README, the release notes and the repo layout on 14 Oct 2026 and compared it with the two browser stacks I already covered. Every number below is attributed to its source, and I have not benchmarked it myself.

1. What Is Moli: Stars, License, and Facts

Moli is Lexmount’s open-source headless browser for AI agents, written in Rust. Its README calls it “a standalone browser kernel, not a Chromium wrapper” and lists a CLI, CDP, WebDriver Classic and WebDriver BiDi as ways to drive it, on Linux, macOS and Windows.

GitHub stars

18,384 (14 Oct 2026)

Repo created

10 Aug 2026

License

MIT OR Apache-2.0

Language

Rust (Cargo workspace)

Latest release

v1.1.17 · 12 Oct 2026

Maintainer

Lexmount

What “headless browser for agents” means here

Most headless setups launch Chrome without a window and talk to it over CDP. Moli is its own engine: libcurl for networking, html5ever for parsing, V8 for JavaScript, Stylo for CSS, Taffy and Parley for layout, and software rendering (AnyRender/Vello CPU) for pixels. “For agents” means outputs shaped for LLMs (Markdown, JSON, semantic text trees) plus the protocols agent frameworks already speak.

Lexmount also sells Lexmount Browser, a managed cloud runtime built around Moli. The README states the open-source browser is fully usable without it, so this guide only covers the open-source binary.

License detail worth knowing

The README says you may use Moli under the Apache 2.0 or the MIT license, at your option, and the workspace Cargo.toml declares MIT OR Apache-2.0. GitHub’s API license field lists only Apache-2.0. Third-party components keep their own licenses (see license-metadata.json and the licenses folder).

2. Architecture in 4 Steps

The design principle in the README is “structure first”: most requests read DOM and runtime state directly, and layout or paint only happen when something needs geometry or pixels.

🌐

Step 1 — Fetch and parse

URL → native DOM

libcurl handles transport and html5ever parses the HTML into a native DOM. Cookie files, HTTP cache and profile directories exist but are off by default.

⚙️

Step 2 — Run the page

DOM → live page state

V8 executes the page’s JavaScript against that DOM. The README lists Fetch, XHR, WebSocket, cookies, WebCrypto and profile-scoped storage as part of the runtime.

📐

Step 3 — Layout on demand

--layout → geometry

Stylo computes style; Taffy and Parley lay out boxes and text only when you pass --layout. The default is mock layout. Real geometry unlocks hit-testing, coordinate input and screenshots.

📤

Step 4 — Emit or serve

page → output or protocol

moli fetch dumps HTML, Markdown, JSON or a semantic text tree (PNG or PDF with --layout). moli serve exposes one endpoint that speaks CDP, WebDriver Classic and WebDriver BiDi.

Cost controls are opt-in

According to the README, expensive work is explicit: --layout turns on real layout, --resource fetches images, fonts, audio, video and text tracks, and persistence flags such as --profile-dir, --http-cache-dir and --cookie-file stay off until you set them.

3. Quickstart: Install and First Fetch

Commands below are quoted from the README and the repo’s webfetch skill file as of 14 Oct 2026. Run moli fetch --help for the full flag list.

Step A — The installer lines, quoted (read before use)

# Linux / macOS, as written in the README. Do not paste blindly.
curl --proto '=https' --tlsv1.2 -fsSL https://github.com/lexmount/moli/releases/latest/download/moli-installer.sh | sh

# Windows PowerShell, as written in the README
powershell -ExecutionPolicy ByPass -c "irm https://github.com/lexmount/moli/releases/latest/download/moli-installer.ps1 | iex"

Read an installer before you run it

Piping a script from the network into a shell runs whatever it serves, as you, immediately. Download moli-installer.sh first and read it. A safer route: the v1.1.17 release lists per-platform archives (tar.gz for Linux and macOS, zip for Windows, x86_64 and aarch64) that you can download, inspect and unpack yourself. The README documents no checksum, package-manager or build-from-source path, and I saw no checksum files in the release assets. Other repositories are also named moli, so install only from the lexmount organization.

The README also offers an agent-install path

The quick start leads with a block of text meant to be handed to an AI coding agent so it installs the project’s skills and a prebuilt binary for you. I did not use it and I am not reproducing it. A prompt like that is a list of instructions your agent will carry out with whatever shell access it has, including downloading code and further instructions. Read the whole text and the skill files it points to (the repo’s skills folder) before pasting it, pin a version, and prefer a sandbox. The project’s own skill file tells agents to treat fetched page text as untrusted, and the same caution applies to install prompts.

Step B — Fetch a page as Markdown

# Markdown of the rendered page (README)
moli fetch --dump markdown --wait-until done https://example.com

# Compact semantic tree, waiting for a selector (README)
moli fetch --dump semantic_tree_text --wait-selector body https://example.com

Per the repo’s skill file, --wait-until accepts done, networkidle or domstable, and --dump also takes html, json, screenshot, screenshot_full and pdf (the last three need --layout). --eval and --eval-file run JavaScript after the page is ready and before export.

Step C — Start the automation server

# DOM-first workloads
moli serve

# real geometry, coordinate input, screenshots
moli serve --layout

# also fetch image, font, audio, video, media and text-track resources
moli serve --layout --resource

// Playwright, as shown in the README
const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");

The README says the same endpoint serves CDP, WebDriver Classic and WebDriver BiDi, and shows Playwright attaching over CDP. That is the documented path. Whether a given agent framework works against Moli’s CDP surface is something to test: the README says unsupported protocol paths return explicit errors instead of faking a result.

4. Moli vs Browser-Use vs Stagehand

These are different layers, not rivals. Browser-Use and Stagehand put an LLM on top of a real Chrome. Moli is the browser underneath. The useful comparison is what sits below the agent and what you give up by swapping it.

Aspect	Moli	Browser-Use	Stagehand
What it is	A browser engine and CLI in Rust	A Python agent framework (LLM loop)	An SDK for TypeScript, Python and Go with act, observe, extract
Browser underneath	Its own kernel (V8, Stylo, Taffy); no Chrome install	A local browser, its cloud, or a remote browser over CDP (README)	Local Chrome (README) or Browserbase cloud
Where the LLM sits	Outside: your agent calls fetch or CDP	Inside: observe, decide, act is the product	Inside the AI primitives; the rest is plain browser control
Default output	Markdown, JSON, HTML, semantic tree; PNG or PDF with --layout	Task result and step history	Extracted data and page actions
Fidelity	Not Chrome-identical; no high-fidelity Canvas, WebGL or media (README)	Whatever the underlying Chrome renders	Whatever the underlying Chrome renders
License · stars (14 Oct 2026)	MIT OR Apache-2.0 · ~18.4k	MIT · ~118k	MIT · ~25.7k

A decision rule

If the agent must behave like a person in a real Chrome (logins, fragile SPAs, pixel-level checks), stay with Browser-Use or Stagehand. If it mostly reads pages and you pay Chrome’s memory on every task, Moli is a candidate runtime to test behind CDP, not a replacement for the agent.

5. Use Cases Where It Fits

These follow from what the README and release notes describe. None of them are claims that I ran the workload.

📄

Pages to Markdown for RAG and agent context

One CLI call turns a JavaScript-rendered page into Markdown, JSON or a compact semantic tree, with no Chrome install. That is the headline use case in the README.

🕷️

Lightweight crawl workers

Many small containers fetching read-only pages, where memory per worker is the bill. The README’s memory comparison with Chrome Headless is self-reported, so measure it on your own URLs.

🎭

A lighter CDP target for Playwright scripts

DOM-first scripts can attach with connectOverCDP as the README shows. Keep Chrome as the fallback for pages that need full fidelity.

🔌

A fetch tool for coding agents

The repo ships skill files for fetching, search and a CDP server, and the v1.1.14 release notes (5 Oct 2026) mention WebMCP support. It is designed to be dropped in as a tool.

The pattern that works

Read-heavy, structure-first tasks where you can diff Moli’s output against Chrome on your own URL list and decide with data.

6. Limits, Self-Reported Numbers, and Responsible Use

Lexmount builds Moli and also maintains the benchmark repo, so treat these figures as vendor claims until you reproduce them.

Mixed crawl, 192 URLs (README)

Moli: 103 useful pages (53.6%), median 1.43 s, 73 MiB RSS. Chrome Headless: 101 pages, 773 MiB. The README gives no date or hardware.

Sample agent workload (README)

CDP ready in 34.85 ms vs 169.37 ms for Chromium; peak PSS 102.46 MiB vs 348.82 MiB. No date or hardware stated.

Lexbench-Headless-Browser (vendor repo, run of 12 Aug 2026)

Build labelled 0.1.1, 1,928 tasks: Moli passed 80.71%, Chrome for Testing 99.90%. Median peak memory 92 MiB vs 697 MiB. That is roughly one task in five that Chrome passes and Moli does not, on a build two months older than v1.1.17.

Independent hands-on (implicator.ai, 12 Oct 2026)

v1.1.16 on one Mac: a JavaScript-rendered page with ten quotes, where curl found none, came back in 0.62 s at about 56 MiB peak. The author calls it one run on one machine and did not measure Chrome.

How I read these together

Large memory savings look plausible and consistent across the vendor’s own tests. Compatibility is the price, and the vendor’s own benchmark shows it. Re-run on your URLs and track success rate, not only megabytes.

Documented limits

From the README project scope (14 Oct 2026): no GUI browser, persistent window or GPU compositor; no pixel-for-pixel parity with Chrome; no high-fidelity Canvas, WebGL or media playback; not every Chrome screenshot or print mode; unsupported protocol paths return explicit errors.

Crawling etiquette and terms

The README does not discuss robots.txt, terms of service or anti-bot measures. The repo contains a moli-robots crate implementing RFC 9309 and the CLI depends on it, but I could not confirm from the docs when fetch applies it, so do not assume it. The repo’s skill file tells agents not to bypass authentication, paywalls, CAPTCHAs or access controls and suggests --block-private-networks for untrusted URLs. Check each site’s robots.txt and terms, rate-limit yourself and use the user-agent override honestly.

7. When NOT to Use Moli

Fast and light only helps if the page comes back right. Skip it when:

⛔ Reach for something else when…

• You need Chrome-identical behavior: pixel checks, Canvas, WebGL, video or complex print output.
• You want an LLM to decide the clicks. Moli is the runtime, not the agent; pair it with Browser-Use or Stagehand.
• The target relies on aggressive bot protection. Nothing in the README addresses that, and engineering around access controls is not a use case to build on.
• You need a long track record: the repo was created on 10 Aug 2026, shipped at least five releases between 4 and 12 Oct, and shows 350 open issues and PRs.
• You cannot accept a curl-to-shell installer or a young dependency chain: the workspace patches several crates to Lexmount forks and vendors V8.

✅ It is worth a test when…

• Your agent mostly reads JavaScript-rendered pages and needs Markdown or JSON.
• You run many parallel, memory-bound workers.
• You already speak CDP or Playwright and want a lighter target.
• You can compare against Chrome on your own URL list first.

Golden rule

Treat Moli as an optimization behind the same interface. Keep a real Chrome as the fallback, pin the version, and measure success rate before you move traffic.

Conclusion

Moli’s pitch is simple: stop paying for a full Chrome when your agent only needs the content of the page. GitHub shows 18,384 stars on a repo created on 10 Aug 2026, and the vendor’s numbers show both the savings and the compatibility gap.

My take: test it where it is strongest, read-only extraction, and keep a real Chrome behind Browser-Use or Stagehand for the interactive parts of the web. And read any installer, human or agent-directed, before it runs.