justrach/kuriAutomatización de navegadores, rastreo web y control de dispositivos iOS + Android para agentes de IA. Instantáneas CDP nativas de Zig y eficientes en tokens, grabación de HAR, cliente nativo del protocolo de cable de adb y un fetcher independiente.
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
ReleaseFastpara 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 dekuri-agent(go→snap→click→snap→eval). Los deltas entre herramientas deberían volver a medirse en el mismo entorno antes de citar un porcentaje.
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.
@eN y al renderizado sin prefijos./page/state (48 tokens) frente al snapshot completo (2.124 tokens) para la misma página de Google Flights.POST /batch envía N comandos en una sola llamada HTTP, eliminando N-1 round-trips y N-1 turnos del LLM.onClick y onChange de React 18/19.SIN → TPENueva 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] |
| 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:
@e0 (3 chars) vs [ref=e0] (9 chars)- por línea (ahorra 2 chars × cantidad de líneas)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) |
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 detiktoken. Vuelve a medir los números entre herramientas en tu propio entorno antes de citar un porcentaje.
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) |
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 |