Moli: navegador headless en Rust para agentes IA (Guía 2026)

Un navegador headless suele significar “Chrome sin ventana”. Moli apuesta por otra cosa: un kernel de navegador independiente en Rust que le entrega la página a un agente IA como Markdown o JSON, y solo pinta píxeles cuando se lo pedís.

Leí el README, las notas de release y la estructura del repo el 14 oct 2026 y lo comparé con los dos stacks de navegador que ya cubrí. Cada número está atribuido a su fuente, y yo no lo medí por mi cuenta.

1. Qué Es Moli: Stars, Licencia y Datos

Moli es el navegador headless open source de Lexmount para agentes IA, escrito en Rust. Su README lo define como “un kernel de navegador independiente, no un wrapper de Chromium” y lista una CLI, CDP, WebDriver Classic y WebDriver BiDi como formas de manejarlo, en Linux, macOS y Windows.

Stars en GitHub

18.384 (14 oct 2026)

Repo creado

10 ago 2026

Licencia

MIT OR Apache-2.0

Lenguaje

Rust (workspace de Cargo)

Última release

v1.1.17 · 12 oct 2026

Mantenedor

Lexmount

Qué significa “navegador headless para agentes” acá

La mayoría de los setups headless lanzan Chrome sin ventana y le hablan por CDP. Moli es su propio motor: libcurl para red, html5ever para parsear, V8 para JavaScript, Stylo para CSS, Taffy y Parley para layout, y render por software (AnyRender/Vello CPU) para los píxeles. “Para agentes” significa salidas pensadas para LLMs (Markdown, JSON, árboles semánticos de texto) más los protocolos que los frameworks de agentes ya hablan.

Lexmount también ofrece Lexmount Browser, un runtime cloud administrado construido alrededor de Moli. El README aclara que el navegador open source se puede usar por completo sin él, así que esta guía cubre solo el binario open source.

Un detalle de la licencia

El README dice que podés usar Moli bajo Apache 2.0 o bajo MIT, a tu elección, y el Cargo.toml del workspace declara MIT OR Apache-2.0. El campo de licencia de la API de GitHub lista solo Apache-2.0. Los componentes de terceros conservan sus propias licencias (mirá license-metadata.json y la carpeta licenses).

2. Arquitectura en 4 Pasos

El principio de diseño del README es “estructura primero”: la mayoría de los pedidos leen el DOM y el estado del runtime directo, y el layout o el paint solo ocurren cuando algo necesita geometría o píxeles.

🌐

Paso 1 — Descargar y parsear

URL → DOM nativo

libcurl maneja el transporte y html5ever parsea el HTML a un DOM nativo. Los archivos de cookies, el cache HTTP y los directorios de perfil existen pero vienen apagados por defecto.

⚙️

Paso 2 — Ejecutar la página

DOM → estado vivo de la página

V8 ejecuta el JavaScript de la página sobre ese DOM. El README lista Fetch, XHR, WebSocket, cookies, WebCrypto y storage por perfil como parte del runtime.

📐

Paso 3 — Layout bajo demanda

--layout → geometría

Stylo calcula el estilo; Taffy y Parley hacen layout de cajas y texto solo cuando pasás --layout. El default es layout simulado. La geometría real habilita hit-testing, input por coordenadas y screenshots.

📤

Paso 4 — Emitir o servir

página → salida o protocolo

moli fetch vuelca HTML, Markdown, JSON o un árbol semántico de texto (PNG o PDF con --layout). moli serve expone un único endpoint que habla CDP, WebDriver Classic y WebDriver BiDi.

Los controles de costo son opt-in

Según el README, el trabajo caro es explícito: --layout activa el layout real, --resource trae imágenes, fuentes, audio, video y text tracks, y las flags de persistencia como --profile-dir, --http-cache-dir y --cookie-file siguen apagadas hasta que las configurás.

3. Quickstart: Instalación y Primer Fetch

Los comandos de abajo están citados del README y del skill de webfetch del repo al 14 oct 2026. Corré moli fetch --help para ver la lista completa de flags.

Paso A — Las líneas del instalador, citadas (leé antes de usar)

# Linux / macOS, tal como figura en el README. No lo pegues a ciegas.
curl --proto '=https' --tlsv1.2 -fsSL https://github.com/lexmount/moli/releases/latest/download/moli-installer.sh | sh

# Windows PowerShell, tal como figura en el README
powershell -ExecutionPolicy ByPass -c "irm https://github.com/lexmount/moli/releases/latest/download/moli-installer.ps1 | iex"

Leé un instalador antes de ejecutarlo

Pasar un script de la red directo a una shell ejecuta lo que sea que sirva, como vos, al instante. Descargá primero moli-installer.sh y leelo. Una ruta más segura: la release v1.1.17 lista archivos por plataforma (tar.gz para Linux y macOS, zip para Windows, x86_64 y aarch64) que podés descargar, inspeccionar y descomprimir vos mismo. El README no documenta checksums, gestores de paquetes ni compilar desde el código fuente, y no vi archivos de checksum en los assets de la release. Además hay otros repositorios que también se llaman moli, así que instalá solo desde la organización lexmount.

El README también ofrece una vía de instalación por agente

El quick start arranca con un bloque de texto pensado para pasárselo a un agente de código con IA para que instale los skills del proyecto y un binario precompilado por vos. No lo usé y no lo reproduzco acá. Un prompt así es una lista de instrucciones que tu agente va a ejecutar con el acceso a shell que tenga, incluyendo descargar código e instrucciones adicionales. Leé el texto completo y los archivos de skill a los que apunta (la carpeta skills del repo) antes de pegarlo, fijá una versión y preferí un sandbox. El propio skill del proyecto le dice a los agentes que traten el texto traído de la web como no confiable, y la misma cautela aplica a los prompts de instalación.

Paso B — Traer una página como Markdown

# Markdown de la página renderizada (README)
moli fetch --dump markdown --wait-until done https://example.com

# Árbol semántico compacto, esperando un selector (README)
moli fetch --dump semantic_tree_text --wait-selector body https://example.com

Según el skill del repo, --wait-until acepta done, networkidle o domstable, y --dump también toma html, json, screenshot, screenshot_full y pdf (los últimos tres necesitan --layout). --eval y --eval-file ejecutan JavaScript cuando la página está lista y antes de exportar.

Paso C — Levantar el servidor de automatización

# cargas DOM-first
moli serve

# geometría real, input por coordenadas, screenshots
moli serve --layout

# además trae recursos de imagen, fuente, audio, video, media y text tracks
moli serve --layout --resource

// Playwright, como muestra el README
const browser = await chromium.connectOverCDP("http://127.0.0.1:9222");

El README dice que el mismo endpoint sirve CDP, WebDriver Classic y WebDriver BiDi, y muestra a Playwright conectándose por CDP. Ese es el camino documentado. Si un framework de agentes en particular funciona contra la superficie CDP de Moli es algo para probar: el README dice que las rutas de protocolo no soportadas devuelven errores explícitos en vez de simular un resultado.

4. Moli vs Browser-Use vs Stagehand

Son capas distintas, no rivales. Browser-Use y Stagehand ponen un LLM encima de un Chrome real. Moli es el navegador que está debajo. La comparación útil es qué hay debajo del agente y qué resignás al cambiarlo.

Aspecto	Moli	Browser-Use	Stagehand
Qué es	Un motor de navegador y CLI en Rust	Un framework de agentes en Python (loop con LLM)	Un SDK para TypeScript, Python y Go con act, observe, extract
Navegador debajo	Su propio kernel (V8, Stylo, Taffy); sin instalar Chrome	Un navegador local, su cloud o un navegador remoto por CDP (README)	Chrome local (README) o cloud de Browserbase
Dónde está el LLM	Afuera: tu agente llama a fetch o a CDP	Adentro: observar, decidir, actuar es el producto	Dentro de las primitivas IA; el resto es control de navegador normal
Salida por defecto	Markdown, JSON, HTML, árbol semántico; PNG o PDF con --layout	Resultado de la tarea e historial de pasos	Datos extraídos y acciones sobre la página
Fidelidad	No es idéntico a Chrome; sin Canvas, WebGL ni media de alta fidelidad (README)	Lo que renderice el Chrome de abajo	Lo que renderice el Chrome de abajo
Licencia · stars (14 oct 2026)	MIT OR Apache-2.0 · ~18,4k	MIT · ~118k	MIT · ~25,7k

Una regla de decisión

Si el agente tiene que comportarse como una persona en un Chrome real (logins, SPAs frágiles, chequeos a nivel píxel), quedate con Browser-Use o Stagehand. Si mayormente lee páginas y pagás la memoria de Chrome en cada tarea, Moli es un runtime candidato para probar detrás de CDP, no un reemplazo del agente.

5. Casos de Uso Donde Encaja

Salen de lo que describen el README y las notas de release. Ninguno es una afirmación de que corrí esa carga de trabajo.

📄

Páginas a Markdown para RAG y contexto de agentes

Una llamada a la CLI convierte una página renderizada con JavaScript en Markdown, JSON o un árbol semántico compacto, sin instalar Chrome. Es el caso de uso principal del README.

🕷️

Workers de crawling livianos

Muchos contenedores chicos trayendo páginas de solo lectura, donde la memoria por worker es la factura. La comparación de memoria del README contra Chrome Headless es autorreportada, así que medila con tus propias URLs.

🎭

Un target CDP más liviano para scripts de Playwright

Los scripts DOM-first pueden conectarse con connectOverCDP como muestra el README. Dejá a Chrome como fallback para las páginas que piden fidelidad completa.

🔌

Una herramienta de fetch para agentes de código

El repo trae archivos de skill para fetch, búsqueda y un servidor CDP, y las notas de la v1.1.14 (5 oct 2026) mencionan soporte de WebMCP. Está pensado para sumarse como herramienta.

El patrón que funciona

Tareas de mucha lectura y estructura primero, donde podés comparar la salida de Moli contra Chrome sobre tu propia lista de URLs y decidir con datos.

6. Límites, Números Autorreportados y Uso Responsable

Lexmount construye Moli y también mantiene el repo del benchmark, así que tratá estas cifras como afirmaciones del proveedor hasta que las reproduzcas.

Crawl mixto, 192 URLs (README)

Moli: 103 páginas útiles (53,6%), mediana 1,43 s, 73 MiB de RSS. Chrome Headless: 101 páginas, 773 MiB. El README no da fecha ni hardware.

Carga de agente de muestra (README)

CDP listo en 34,85 ms vs 169,37 ms de Chromium; PSS pico 102,46 MiB vs 348,82 MiB. Sin fecha ni hardware.

Lexbench-Headless-Browser (repo del proveedor, corrida del 12 ago 2026)

Build etiquetado 0.1.1, 1.928 tareas: Moli pasó el 80,71%, Chrome for Testing el 99,90%. Memoria pico mediana 92 MiB vs 697 MiB. Es más o menos una tarea de cada cinco que Chrome pasa y Moli no, sobre un build dos meses más viejo que la v1.1.17.

Prueba independiente (implicator.ai, 12 oct 2026)

v1.1.16 en una Mac: una página renderizada con JavaScript con diez frases, donde curl no encontró ninguna, volvió en 0,62 s con unos 56 MiB de pico. El autor lo llama una corrida en una máquina y no midió Chrome.

Cómo leo todo esto junto

Los grandes ahorros de memoria se ven plausibles y consistentes en las pruebas del propio proveedor. La compatibilidad es el precio, y el benchmark del proveedor lo muestra. Repetí la prueba con tus URLs y seguí la tasa de éxito, no solo los megabytes.

Límites documentados

Del alcance del proyecto en el README (14 oct 2026): sin navegador con GUI, ventana persistente ni compositor GPU; sin paridad píxel a píxel con Chrome; sin Canvas, WebGL ni reproducción de media de alta fidelidad; no todos los modos de screenshot o impresión de Chrome; las rutas de protocolo no soportadas devuelven errores explícitos.

Etiqueta de crawling y términos

El README no habla de robots.txt, términos de servicio ni medidas anti-bot. El repo contiene un crate moli-robots que implementa el RFC 9309 y la CLI depende de él, pero no pude confirmar en la documentación cuándo lo aplica fetch, así que no lo des por hecho. El skill del repo le indica a los agentes no saltear autenticación, paywalls, CAPTCHAs ni controles de acceso y sugiere --block-private-networks para URLs no confiables. Revisá el robots.txt y los términos de cada sitio, limitá tu ritmo y usá el override de user-agent con honestidad.

7. Cuándo NO Usar Moli

Rápido y liviano solo sirve si la página vuelve bien. Saltealo cuando:

⛔ Buscá otra cosa cuando…

• Necesitás comportamiento idéntico a Chrome: chequeos de píxeles, Canvas, WebGL, video o salidas de impresión complejas.
• Querés que un LLM decida los clicks. Moli es el runtime, no el agente; combinalo con Browser-Use o Stagehand.
• El objetivo depende de protección anti-bot agresiva. Nada en el README lo aborda, y sortear controles de acceso no es un caso de uso sobre el que construir.
• Necesitás un historial largo: el repo se creó el 10 ago 2026, sacó al menos cinco releases entre el 4 y el 12 de oct, y muestra 350 issues y PRs abiertos.
• No podés aceptar un instalador curl a shell ni una cadena de dependencias joven: el workspace parchea varios crates con forks de Lexmount y vendorea V8.

✅ Vale la pena probarlo cuando…

• Tu agente mayormente lee páginas renderizadas con JavaScript y necesita Markdown o JSON.
• Corrés muchos workers en paralelo limitados por memoria.
• Ya hablás CDP o Playwright y querés un target más liviano.
• Podés comparar contra Chrome sobre tu propia lista de URLs antes.

Regla de oro

Tratá a Moli como una optimización detrás de la misma interfaz. Dejá un Chrome real como fallback, fijá la versión y medí la tasa de éxito antes de mover tráfico.

Conclusión

La propuesta de Moli es simple: dejá de pagar un Chrome completo cuando tu agente solo necesita el contenido de la página. GitHub muestra 18.384 stars en un repo creado el 10 ago 2026, y los números del proveedor muestran tanto el ahorro como la brecha de compatibilidad.

Mi opinión: probalo donde es más fuerte, la extracción de solo lectura, y mantené un Chrome real detrás de Browser-Use o Stagehand para las partes interactivas de la web. Y leé cualquier instalador, humano o dirigido a un agente, antes de que se ejecute.