Kuri 🌰

Installation

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

macOS arm64/x86_64 und Linux x86_64/arm64. Einzelne Binärdatei, keine Laufzeitabhängigkeiten.

Direkte Downloads: macOS arm64 · macOS x86_64 · Linux x86_64 · Linux arm64

---

Browser-Automatisierung & Web-Crawling für KI-Agenten. Geschrieben in Zig. Null Node.js.

CDP-Automatisierung · A11y-Snapshots · HAR-Aufzeichnung · Standalone-Fetcher · Interaktiver Terminal-Browser · Agentic CLI · Sicherheitstests · iOS- + Android-Gerätesteuerung

Schnellstart · Benchmarks · kuri-agent · Sicherheitstests · API · Skills · Changelog

Warum Teams zu Kuri wechseln: Aktuelle Apple-Silicon-ReleaseFast-Builds bleiben unter 2 MB pro Binärdatei, und ein frischer Google-Flights-Durchlauf am 2026-04-23 maß 3.392 Tokens für eine vollständige kuri-agent-Schleife (go→snap→click→snap→eval). Tool-übergreifende Deltas sollten in derselben Umgebung erneut ausgeführt werden, bevor ein Prozentsatz zitiert wird.

---

Warum Kuri für Agenten gewinnt

Die meisten Browser-Tools wurden für QA-Ingenieure entwickelt. Kuri ist für Agenten-Schleifen gebaut: die Seite lesen, Token-Kosten niedrig halten, auf stabile Refs reagieren und weitermachen.

• 135 HTTP-Endpunkte — vollständige Parität mit agent-browser und browser-use, von React-Inspektion bis Core Web Vitals.
• 7-12 % weniger Tokens als agent-browser auf echten Seiten dank @eN-Ref-Format und Zero-Prefix-Rendering.
• 44x leichtere Beobachtungen mit /page/state (48 Tokens) vs. vollständigem Snapshot (2.124 Tokens) für dieselbe Google-Flights-Seite.
• Batch-Ausführung — POST /batch sendet N Befehle in einem HTTP-Aufruf und eliminiert N-1 Round-Trips und N-1 LLM-Turns.
• React-kompatibel — vertrauenswürdige CDP-Mausereignisse und Zeichen-für-Zeichen-Tastenereignisse lösen React 18/19 onClick und onChange aus.

Snapshot-Tokens: Google Flights SIN → TPE

Frischer Durchlauf am 2026-05-24 in diesem Workspace, gemessen mit wc -c und chars/4-Approximation.

Tool / Modus	Zeichen	~Tokens	Hinweis
kuri snap (vollständig)	8.499	2.124	Alle Knoten + interaktive Refs
kuri snap (nur interaktiv)	~3.000	~750	Am besten für Agenten-Schleifen
kuri /page/state	190	48	Leichtgewichtige Beobachtung (url, title, scroll%, counts)
agent-browser snap (geschätzt)	~9.183	~2.295	[ref=e0]-Format-Overhead

Token-Effizienz: kuri vs agent-browser

Seite	kuri-Tokens	agent-browser-Tokens	Ersparnis
example.com	40	35	-13 % (triviale Seite, agent-browser überspringt Root)
Hacker News	386	~440	12 % weniger
Google Flights SIN→TPE	2.124	~2.295	7 % weniger

Die Ersparnis kommt von kuris kompaktem Format:

• @e0-Refs (3 Zeichen) vs. [ref=e0] (9 Zeichen)
• Kein - -Präfix pro Zeile (spart 2 Zeichen × Zeilenanzahl)
• Gleiche Einrückung, gleiche Knotenfilterung

Vollständige Workflow-Kosten: go → snap → click → snap → eval

Tool	Tokens pro Zyklus
kuri-agent	~3.400
Mit /page/state statt zweitem Snap	~1.700
Mit POST /batch (alles in einem Aufruf)	~1.700 (gleiche Tokens, 1 HTTP-Aufruf statt 5)

kuri vs libretto

libretto (Playwright + Node) ist der engste Konkurrent bei den Token-Kosten pro Schritt. Direktvergleich am 2026-07-04 gemessen — gleicher Chrome, gleicher Tab, echte tiktoken-o200k_base-Zählungen (vollständige Methodik und Reproduktion: benchmarks/libretto_comparison.md). Die ehrliche Aufteilung:

Achse	Gewinner	Detail
Latenz pro Aufruf	kuri	4–117 ms vs. 1.344–1.500 ms (13–376× schneller — persistenter Server vs. Node-pro-Befehl)
Snapshot-Tokens, typische Seite	kuri	einfach 61 vs. 151 (2,5×), Artikel 265 vs. 363 (1,37×) — straffere Grammatik
Snapshot-Tokens, große Liste	geteilt	kuri-Standard 4.424 vs. 813 — kuri gibt alle 259 Refs aus, libretto kürzt standardmäßig. Mit limit=5 rendert kuri 555 Tokens (1,46× unter libretto), 34 Refs + … +45 more-Marker
Trajektorie (Feed, 9 Klicks)	kuri, knapp	898 vs. 939 Tokens (limit=5-Basis + Diff-Schleife vs. Exec-Schleife) — Parität bis leichter Vorteil; der 5,1×-Verlust am Morgen war die ungekürzte Basis
Wiederholte Durchläufe	libretto	kompiliert Trajektorien zu einem Playwright-Skript → 0-Token-Wiederholungen; kuri zahlt die Schleife bei jedem Durchlauf erneut

Was kuri aus dem Studium von libretto gewonnen hat (alles in diesem Release ausgeliefert): eine Diff-First-Schleife (take_snapshot_diff, ~38 Tokens/Schritt); ein adaptiver Diff, der bei Navigation auf einen vollständigen Snapshot mit ! page replaced-Header zurückfällt; reine Identitäts-Entfernungszeilen; Screenshots auf die Festplatte geschrieben (Pfad zurückgegeben, Bytes gelangen nie in den Kontext); get_page_state über MCP; und — nach dem Umschreiben von parseA11yNodes als echten DFS-Baumdurchlauf — Opt-in-Listenkürzung (/snapshot?limit=N, eine … +K more-Zeile pro gekapptem Durchlauf), bereichsbezogene Neuerfassung (scope=@ref) und Hierarchie-Einrückung, ebenfalls als uid/limit bei MCP take_snapshot verfügbar. Die 9-Klick-Feed-Trajektorie, die mit naiven vollständigen Re-Snapshots 44.285 Tokens kostete, kostet mit gekürzter Basis + Diffs 898 — 49× günstiger und über librettos 939.

Die älteren Tabellen oben verwenden eine chars/4-Token-Approximation; der libretto-Vergleich verwendet echte tiktoken-Zählungen. Führen Sie tool-übergreifende Zahlen in Ihrer eigenen Umgebung erneut aus, bevor Sie einen Prozentsatz zitieren.

Binärgröße und Speicher

Gemessen auf Apple M4 Pro, macOS 26.4.1. Aktuelle Binärdateien wurden mit -Doptimize=ReleaseFast gebaut.

Binärdatei	Aktuelle Größe
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)

RSS blieb während der Zig-0.16-Migration flach

Gemessen gegen den aktuellen v0.4.3-ReleaseFast-Build mit /usr/bin/time -l.

Befehl	v0.4.3 mittleres max. RSS
kuri-fetch --version	~2,45 MiB
kuri-browse --version	~2,45 MiB
kuri-fetch --quiet --dump markdown http://example.com/	~9,17 MiB

Das Problem