Kuri 🌰

Installazione

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

macOS arm64/x86_64 e Linux x86_64/arm64. Binario singolo, nessuna dipendenza runtime.

Download diretti: macOS arm64 · macOS x86_64 · Linux x86_64 · Linux arm64

---

Automazione browser e web crawling per agenti AI. Scritto in Zig. Zero Node.js.

Automazione CDP · Snapshot A11y · Registrazione HAR · Fetcher standalone · Browser terminale interattivo · CLI agentica · Security testing · Controllo dispositivi iOS + Android

Quick Start · Benchmarks · kuri-agent · Security Testing · API · Skills · Changelog

Perché i team passano a Kuri: le build ReleaseFast attuali per Apple Silicon restano sotto i 2 MB per binario, e una nuova esecuzione di Google Flights il 2026-04-23 ha misurato 3.392 token per un ciclo completo di kuri-agent (go→snap→click→snap→eval). I delta tra strumenti dovrebbero essere rieseguiti nello stesso ambiente prima di citare una percentuale.

---

Perché Kuri Vince per gli Agenti

La maggior parte degli strumenti per browser è stata creata per ingegneri QA. Kuri è costruito per i cicli degli agenti: leggere la pagina, mantenere basso il costo in token, agire su riferimenti stabili e andare avanti.

• 135 endpoint HTTP — piena parità con agent-browser e browser-use, dall'ispezione React ai Core Web Vitals.
• 7-12% in meno di token rispetto ad agent-browser su pagine reali grazie al formato di riferimento @eN e al rendering senza prefissi.
• Osservazioni 44 volte più leggere con /page/state (48 token) rispetto allo snapshot completo (2.124 token) per la stessa pagina di Google Flights.
• Esecuzione batch — POST /batch invia N comandi in una singola chiamata HTTP, eliminando N-1 round-trip e N-1 turni LLM.
• Compatibile con React — eventi mouse CDP affidabili ed eventi tastiera per carattere attivano onClick e onChange di React 18/19.

Token degli snapshot: Google Flights SIN → TPE

Nuova esecuzione il 2026-05-24 in questo workspace, misurata con wc -c e approssimazione chars/4.

Strumento / Modalità	Caratteri	~Token	Nota
kuri snap (completo)	8.499	2.124	Tutti i nodi + riferimenti interattivi
kuri snap (solo interattivi)	~3.000	~750	Ideale per i cicli degli agenti
kuri /page/state	190	48	Osservazione leggera (url, title, scroll%, conteggi)
agent-browser snap (stimato)	~9.183	~2.295	Overhead del formato [ref=e0]

Efficienza dei token: kuri vs agent-browser

Pagina	token kuri	token agent-browser	Risparmio
example.com	40	35	-13% (pagina banale, agent-browser salta la root)
Hacker News	386	~440	12% in meno
Google Flights SIN→TPE	2.124	~2.295	7% in meno

Il risparmio deriva dal formato compatto di kuri:

• riferimenti @e0 (3 caratteri) vs [ref=e0] (9 caratteri)
• Nessun prefisso - per riga (risparmia 2 caratteri × numero di righe)
• Stessa indentazione, stesso filtraggio dei nodi

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

Strumento	Token per ciclo
kuri-agent	~3.400
Con /page/state invece del secondo snap	~1.700
Con POST /batch (tutto in una chiamata)	~1.700 (stessi token, 1 chiamata HTTP invece di 5)

kuri vs libretto

libretto (Playwright + Node) è il concorrente più vicino sul costo in token per passo. Misurato testa a testa il 2026-07-04 — stesso Chrome, stessa scheda, conteggi reali tiktoken o200k_base (metodologia completa e riproduzione: benchmarks/libretto_comparison.md). La divisione onesta:

Asse	Vincitore	Dettaglio
Latenza per chiamata	kuri	4–117 ms vs 1.344–1.500 ms (13–376× più veloce — server persistente vs Node-per-comando)
Token snapshot, pagina tipica	kuri	semplice 61 vs 151 (2,5×), articolo 265 vs 363 (1,37×) — grammatica più compatta
Token snapshot, lista grande	pari	kuri default 4.424 vs 813 — kuri emette tutti i 259 riferimenti, libretto tronca per default. Con limit=5 kuri renderizza 555 token (1,46× sotto libretto), 34 riferimenti + marcatori … +45 more
Traiettoria (feed, 9 click)	kuri, di poco	898 vs 939 token (base limit=5 + ciclo diff vs ciclo exec) — parità o leggero vantaggio; la perdita di 5,1× del mattino era la base non troncata
Esecuzioni ripetute	libretto	compila le traiettorie in uno script Playwright → replay a 0 token; kuri ripaga il ciclo a ogni esecuzione

Cosa ha guadagnato kuri studiando libretto (tutto rilasciato in questa versione): un ciclo diff-first (take_snapshot_diff, ~38 token/passo); un diff adattivo che ricade su uno snapshot completo con un'intestazione ! page replaced in caso di navigazione; righe di rimozione solo per identità; screenshot scritti su disco (percorso restituito, i byte non entrano mai nel contesto); get_page_state su MCP; e — dopo aver riscritto parseA11yNodes come una vera visita DFS dell'albero — troncamento opt-in delle liste (/snapshot?limit=N, una riga … +K more per ogni esecuzione limitata), ri-acquisizione con scope (scope=@ref) e indentazione gerarchica, esposti anche come uid/limit su MCP take_snapshot. La traiettoria del feed con 9 click che costava 44.285 token con ingenui re-snapshot completi costa 898 con una base troncata + diff — 49× più economica, e oltre i 939 di libretto.

Le tabelle più vecchie sopra usano un'approssimazione di token chars/4; il confronto con libretto usa conteggi reali tiktoken. Riesegui i numeri tra strumenti nel tuo ambiente prima di citare una percentuale.

Dimensione del binario e memoria

Misurato su Apple M4 Pro, macOS 26.4.1. I binari attuali sono stati compilati con -Doptimize=ReleaseFast.

Binario	Dimensione attuale
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)

L'RSS è rimasto stabile durante la migrazione a Zig 0.16

Misurato sulla build ReleaseFast attuale v0.4.3 con /usr/bin/time -l.

Comando	RSS massimo medio 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

Il Problema