Kuri 🌰

Instalación

curl -fsSL https://kuri.trilok.ai/download | sh

macOS arm64/x86_64 y Linux x86_64/arm64. Binario único, sin dependencias de runtime.

Descargas directas: macOS arm64 · macOS x86_64 · Linux x86_64 · Linux arm64

---

Automatización de navegador y web crawling para agentes de IA. Escrito en Zig. Cero Node.js.

Automatización CDP · Snapshots de A11y · Grabación HAR · Fetcher autónomo · Navegador de terminal interactivo · CLI agéntico · Pruebas de seguridad · Control de dispositivos iOS + Android

Inicio rápido · Benchmarks · kuri-agent · Pruebas de seguridad · API · Skills · Changelog

Por qué los equipos cambian a Kuri: las compilaciones actuales ReleaseFast para Apple Silicon se mantienen por debajo de 2 MB por binario, y una nueva ejecución de Google Flights el 2026-04-23 midió 3.392 tokens para un ciclo completo de kuri-agent (go→snap→click→snap→eval). Los deltas entre herramientas deberían volver a medirse en el mismo entorno antes de citar un porcentaje.

---

Por qué Kuri gana para agentes

La mayoría de las herramientas de navegador fueron creadas para ingenieros de QA. Kuri está creado para ciclos de agentes: leer la página, mantener bajo el costo en tokens, actuar sobre refs estables y seguir adelante.

• 135 endpoints HTTP — paridad total con agent-browser y browser-use, desde inspección de React hasta Core Web Vitals.
• 7-12% menos tokens que agent-browser en páginas reales gracias al formato de refs @eN y al renderizado sin prefijos.
• Observaciones 44x más ligeras con /page/state (48 tokens) frente al snapshot completo (2.124 tokens) para la misma página de Google Flights.
• Ejecución por lotes — POST /batch envía N comandos en una sola llamada HTTP, eliminando N-1 round-trips y N-1 turnos del LLM.
• Compatible con React — eventos de mouse CDP confiables y eventos de teclado por carácter disparan onClick y onChange de React 18/19.

Tokens de snapshot: Google Flights SIN → TPE

Nueva ejecución el 2026-05-24 en este workspace, medida con wc -c y aproximación chars/4.

Herramienta / Modo	Chars	~Tokens	Nota
kuri snap (completo)	8.499	2.124	Todos los nodos + refs interactivos
kuri snap (solo interactivos)	~3.000	~750	Mejor para ciclos de agentes
kuri /page/state	190	48	Observación ligera (url, title, scroll%, counts)
agent-browser snap (estimado)	~9.183	~2.295	Sobrecarga del formato [ref=e0]

Eficiencia de tokens: kuri vs agent-browser

Página	tokens de kuri	tokens de agent-browser	Ahorro
example.com	40	35	-13% (página trivial, agent-browser omite la raíz)
Hacker News	386	~440	12% menos
Google Flights SIN→TPE	2.124	~2.295	7% menos

El ahorro proviene del formato compacto de kuri:

• refs @e0 (3 chars) vs [ref=e0] (9 chars)
• Sin prefijo - por línea (ahorra 2 chars × cantidad de líneas)
• Misma indentación, mismo filtrado de nodos

Costo del flujo completo: go → snap → click → snap → eval

Herramienta	Tokens por ciclo
kuri-agent	~3.400
Con /page/state en lugar del segundo snap	~1.700
Con POST /batch (todo en una llamada)	~1.700 (mismos tokens, 1 llamada HTTP en lugar de 5)

kuri vs libretto

libretto (Playwright + Node) es el competidor más cercano en costo de tokens por paso. Medido cara a cara el 2026-07-04 — mismo Chrome, misma pestaña, conteos reales de tiktoken o200k_base (metodología completa y reproducción: benchmarks/libretto_comparison.md). La división honesta:

Eje	Ganador	Detalle
Latencia por llamada	kuri	4–117 ms vs 1.344–1.500 ms (13–376× más rápido — servidor persistente vs Node por comando)
Tokens de snapshot, página típica	kuri	simple 61 vs 151 (2,5×), artículo 265 vs 363 (1,37×) — gramática más ajustada
Tokens de snapshot, lista grande	empate	kuri por defecto 4.424 vs 813 — kuri emite las 259 refs, libretto trunca por defecto. Con limit=5 kuri renderiza 555 tokens (1,46× por debajo de libretto), 34 refs + marcadores … +45 more
Trayectoria (feed, 9 clics)	kuri, apenas	898 vs 939 tokens (base limit=5 + bucle de diff vs bucle exec) — paridad a ligera ventaja; la pérdida de 5,1× de la mañana era la base sin truncar
Ejecuciones repetidas	libretto	compila trayectorias a un script de Playwright → repeticiones de 0 tokens; kuri vuelve a pagar el bucle en cada ejecución

Lo que kuri ganó al estudiar libretto (todo incluido en esta versión): un bucle diff-first (take_snapshot_diff, ~38 tokens/paso); un diff adaptativo que recurre a un snapshot completo con un encabezado ! page replaced en la navegación; líneas de eliminación solo de identidad; capturas de pantalla escritas a disco (se devuelve la ruta, los bytes nunca entran al contexto); get_page_state sobre MCP; y — tras reescribir parseA11yNodes como un verdadero recorrido DFS del árbol — truncado de listas opcional (/snapshot?limit=N, una línea … +K more por ejecución limitada), recaptura con alcance (scope=@ref) e indentación jerárquica, también expuestos como uid/limit en el take_snapshot de MCP. La trayectoria de feed de 9 clics que costaba 44.285 tokens con re-snapshots completos ingenuos cuesta 898 con una base truncada + diffs — 49× más barato, y por encima de los 939 de libretto.

Las tablas anteriores más antiguas usan una aproximación de tokens chars/4; la comparación con libretto usa conteos reales de tiktoken. Vuelve a medir los números entre herramientas en tu propio entorno antes de citar un porcentaje.

Tamaño del binario y memoria

Medido en Apple M4 Pro, macOS 26.4.1. Los binarios actuales se compilaron con -Doptimize=ReleaseFast.

Binario	Tamaño actual
kuri	1.093.840 B (1,04 MiB)
kuri-agent	629.904 B (615 KiB)
kuri-browse	1.089.120 B (1,04 MiB)
kuri-fetch	2.063.488 B (1,97 MiB)

El RSS se mantuvo estable durante la migración a Zig 0.16

Medido contra la compilación actual v0.4.3 ReleaseFast con /usr/bin/time -l.

Comando	RSS máximo medio de v0.4.3
kuri-fetch --version	~2,45 MiB
kuri-browse --version	~2,45 MiB
kuri-fetch --quiet --dump markdown http://example.com/	~9,17 MiB

El problema