Kuri 🌰

Installation

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

macOS arm64/x86_64 et Linux x86_64/arm64. Binaire unique, aucune dépendance d'exécution.

Téléchargements directs : macOS arm64 · macOS x86_64 · Linux x86_64 · Linux arm64

---

Automatisation de navigateur et crawling web pour agents IA. Écrit en Zig. Zéro Node.js.

Automatisation CDP · Instantanés A11y · Enregistrement HAR · Récupérateur autonome · Navigateur terminal interactif · CLI agentique · Tests de sécurité · Contrôle d'appareils iOS + Android

Démarrage rapide · Benchmarks · kuri-agent · Tests de sécurité · API · Skills · Changelog

Pourquoi les équipes passent à Kuri : les builds ReleaseFast actuels sur Apple Silicon restent sous les 2 Mo par binaire, et une nouvelle exécution de Google Flights le 2026-04-23 a mesuré 3 392 tokens pour une boucle kuri-agent complète (go→snap→click→snap→eval). Les écarts entre outils doivent être remesurés dans le même environnement avant de citer un pourcentage.

---

Pourquoi Kuri gagne pour les agents

La plupart des outils d'automatisation de navigateur ont été conçus pour les ingénieurs QA. Kuri est conçu pour les boucles d'agents : lire la page, garder un coût en tokens faible, agir sur des références stables, et passer à la suite.

• 135 endpoints HTTP — parité complète avec agent-browser et browser-use, de l'inspection React aux Core Web Vitals.
• 7 à 12 % de tokens en moins qu'agent-browser sur des pages réelles grâce au format de référence @eN et au rendu sans préfixe.
• Observations 44× plus légères avec /page/state (48 tokens) contre un instantané complet (2 124 tokens) pour la même page Google Flights.
• Exécution par lots — POST /batch envoie N commandes en un seul appel HTTP, éliminant N-1 allers-retours et N-1 tours de LLM.
• Compatible React — les événements souris CDP de confiance et les événements clavier caractère par caractère déclenchent les onClick et onChange de React 18/19.

Tokens d'instantané : Google Flights SIN → TPE

Nouvelle exécution le 2026-05-24 dans cet espace de travail, mesurée avec wc -c et l'approximation chars/4.

Outil / Mode	Caractères	~Tokens	Remarque
kuri snap (complet)	8 499	2 124	Tous les nœuds + références interactives
kuri snap (interactif uniquement)	~3 000	~750	Idéal pour les boucles d'agents
kuri /page/state	190	48	Observation légère (url, title, scroll%, counts)
agent-browser snap (estimé)	~9 183	~2 295	Surcoût du format [ref=e0]

Efficacité des tokens : kuri vs agent-browser

Page	tokens kuri	tokens agent-browser	Économie
example.com	40	35	-13 % (page triviale, agent-browser ignore la racine)
Hacker News	386	~440	12 % de moins
Google Flights SIN→TPE	2 124	~2 295	7 % de moins

Les économies proviennent du format compact de kuri :

• Références @e0 (3 caractères) contre [ref=e0] (9 caractères)
• Aucun préfixe - par ligne (économise 2 caractères × nombre de lignes)
• Même indentation, même filtrage des nœuds

Coût complet du workflow : go → snap → click → snap → eval

Outil	Tokens par cycle
kuri-agent	~3 400
Avec /page/state au lieu du second snap	~1 700
Avec POST /batch (tout en un seul appel)	~1 700 (mêmes tokens, 1 appel HTTP au lieu de 5)

kuri vs libretto

libretto (Playwright + Node) est le concurrent le plus proche sur le coût en tokens par étape. Mesuré en confrontation directe le 2026-07-04 — même Chrome, même onglet, comptages réels tiktoken o200k_base (méthodologie complète et reproduction : benchmarks/libretto_comparison.md). Le partage honnête :

Axe	Gagnant	Détail
Latence par appel	kuri	4–117 ms contre 1 344–1 500 ms (13–376× plus rapide — serveur persistant contre Node-par-commande)
Tokens d'instantané, page typique	kuri	simple 61 contre 151 (2,5×), article 265 contre 363 (1,37×) — grammaire plus serrée
Tokens d'instantané, grande liste	partagé	kuri par défaut 4 424 contre 813 — kuri émet les 259 références, libretto tronque par défaut. Avec limit=5, kuri rend 555 tokens (1,46× sous libretto), 34 références + marqueurs … +45 more
Trajectoire (feed, 9 clics)	kuri, de justesse	898 contre 939 tokens (base limit=5 + boucle de diff contre boucle exec) — parité à léger avantage ; la perte de 5,1× du matin était due à la base non tronquée
Exécutions répétées	libretto	compile les trajectoires en un script Playwright → rejeux à 0 token ; kuri repaie la boucle à chaque exécution

Ce que kuri a gagné en étudiant libretto (tout livré dans cette version) : une boucle diff-first (take_snapshot_diff, ~38 tokens/étape) ; un diff adaptatif qui retombe sur un instantané complet avec un en-tête ! page replaced lors d'une navigation ; des lignes de suppression d'identité uniquement ; des captures d'écran écrites sur disque (chemin retourné, les octets n'entrent jamais dans le contexte) ; get_page_state via MCP ; et — après réécriture de parseA11yNodes en véritable parcours d'arbre DFS — la troncature de liste optionnelle (/snapshot?limit=N, une ligne … +K more par exécution plafonnée), la recapture ciblée (scope=@ref), et l'indentation hiérarchique, également exposées comme uid/limit sur le take_snapshot MCP. La trajectoire de feed à 9 clics qui coûtait 44 285 tokens avec des re-snapshots complets naïfs coûte 898 avec une base tronquée + diffs — 49× moins cher, et au-delà des 939 de libretto.

Les tableaux plus anciens ci-dessus utilisent une approximation de tokens chars/4 ; la comparaison avec libretto utilise de vrais comptages tiktoken. Remesurez les chiffres entre outils dans votre propre environnement avant de citer un pourcentage.

Taille des binaires et mémoire

Mesuré sur Apple M4 Pro, macOS 26.4.1. Les binaires actuels ont été compilés avec -Doptimize=ReleaseFast.

Binaire	Taille actuelle
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)

Le RSS est resté stable durant la migration vers Zig 0.16

Mesuré sur le build ReleaseFast actuel v0.4.3 avec /usr/bin/time -l.