Kuri 🌰

Instalação

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

macOS arm64/x86_64 e Linux x86_64/arm64. Binário único, sem dependências de runtime.

Downloads diretos: macOS arm64 · macOS x86_64 · Linux x86_64 · Linux arm64

---

Automação de navegador e web crawling para agentes de IA. Escrito em Zig. Zero Node.js.

Automação CDP · Snapshots A11y · Gravação HAR · Fetcher autônomo · Navegador de terminal interativo · CLI agêntica · Testes de segurança · Controle de dispositivos iOS + Android

Início Rápido · Benchmarks · kuri-agent · Testes de Segurança · API · Skills · Changelog

Por que as equipes migram para o Kuri: as builds atuais ReleaseFast para Apple Silicon permanecem abaixo de 2 MB por binário, e uma nova execução do Google Flights em 2026-04-23 mediu 3.392 tokens para um ciclo completo do kuri-agent (go→snap→click→snap→eval). Deltas entre ferramentas devem ser reexecutados no mesmo ambiente antes de citar uma porcentagem.

---

Por que o Kuri Vence para Agentes

A maioria das ferramentas de navegador foi criada para engenheiros de QA. O Kuri foi criado para ciclos de agentes: ler a página, manter o custo de tokens baixo, agir sobre refs estáveis e seguir em frente.

• 135 endpoints HTTP — paridade total com agent-browser e browser-use, da inspeção React aos Core Web Vitals.
• 7-12% menos tokens que o agent-browser em páginas reais graças ao formato de ref @eN e renderização sem prefixo.
• Observações 44x mais leves com /page/state (48 tokens) vs snapshot completo (2.124 tokens) para a mesma página do Google Flights.
• Execução em lote — POST /batch envia N comandos em uma única chamada HTTP, eliminando N-1 round-trips e N-1 turnos do LLM.
• Compatível com React — eventos de mouse CDP confiáveis e eventos de tecla por caractere disparam onClick e onChange do React 18/19.

Tokens de snapshot: Google Flights SIN → TPE

Nova execução em 2026-05-24 neste workspace, medida com wc -c e aproximação chars/4.

Ferramenta / Modo	Chars	~Tokens	Nota
kuri snap (completo)	8.499	2.124	Todos os nós + refs interativas
kuri snap (somente interativo)	~3.000	~750	Melhor para ciclos de agentes
kuri /page/state	190	48	Observação leve (url, title, scroll%, contagens)
agent-browser snap (estimado)	~9.183	~2.295	Overhead do formato [ref=e0]

Eficiência de tokens: kuri vs agent-browser

Página	tokens kuri	tokens agent-browser	Economia
example.com	40	35	-13% (página trivial, agent-browser pula a raiz)
Hacker News	386	~440	12% menos
Google Flights SIN→TPE	2.124	~2.295	7% menos

A economia vem do formato compacto do kuri:

• refs @e0 (3 chars) vs [ref=e0] (9 chars)
• Sem prefixo - por linha (economiza 2 chars × número de linhas)
• Mesma indentação, mesma filtragem de nós

Custo do fluxo completo: go → snap → click → snap → eval

Ferramenta	Tokens por ciclo
kuri-agent	~3.400
Com /page/state em vez do segundo snap	~1.700
Com POST /batch (tudo em uma chamada)	~1.700 (mesmos tokens, 1 chamada HTTP em vez de 5)

kuri vs libretto

libretto (Playwright + Node) é o concorrente mais próximo em custo de tokens por passo. Medido frente a frente em 2026-07-04 — mesmo Chrome, mesma aba, contagens reais de tiktoken o200k_base (metodologia completa e reprodução: benchmarks/libretto_comparison.md). A divisão honesta:

Eixo	Vencedor	Detalhe
Latência por chamada	kuri	4–117 ms vs 1.344–1.500 ms (13–376× mais rápido — servidor persistente vs Node-por-comando)
Tokens de snapshot, página típica	kuri	simples 61 vs 151 (2,5×), artigo 265 vs 363 (1,37×) — gramática mais enxuta
Tokens de snapshot, lista grande	dividido	kuri padrão 4.424 vs 813 — kuri emite todas as 259 refs, libretto trunca por padrão. Com limit=5 kuri renderiza 555 tokens (1,46× abaixo do libretto), 34 refs + marcadores … +45 more
Trajetória (feed, 9 cliques)	kuri, por pouco	898 vs 939 tokens (base limit=5 + loop de diff vs loop exec) — paridade a leve vantagem; a perda de 5,1× da manhã era a base não truncada
Execuções repetidas	libretto	compila trajetórias para um script Playwright → replays de 0 token; kuri repaga o loop a cada execução

O que o kuri ganhou ao estudar o libretto (tudo lançado nesta versão): um loop diff-first (take_snapshot_diff, ~38 tokens/passo); um diff adaptativo que recorre a um snapshot completo com cabeçalho ! page replaced na navegação; linhas de remoção apenas de identidade; screenshots gravados em disco (caminho retornado, bytes nunca entram no contexto); get_page_state via MCP; e — após reescrever parseA11yNodes como uma verdadeira travessia DFS de árvore — truncamento de lista opt-in (/snapshot?limit=N, uma linha … +K more por execução limitada), recaptura com escopo (scope=@ref) e indentação de hierarquia, também expostos como uid/limit no take_snapshot do MCP. A trajetória de feed com 9 cliques que custava 44.285 tokens com re-snapshots completos ingênuos custa 898 com base truncada + diffs — 49× mais barato, e superando os 939 do libretto.

As tabelas mais antigas acima usam uma aproximação de tokens chars/4; a comparação com o libretto usa contagens reais de tiktoken. Reexecute os números entre ferramentas no seu próprio ambiente antes de citar uma porcentagem.

Tamanho do binário e memória

Medido em Apple M4 Pro, macOS 26.4.1. Os binários atuais foram compilados com -Doptimize=ReleaseFast.

Binário	Tamanho atual
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 permaneceu estável durante a migração para Zig 0.16

Medido com a build atual v0.4.3 ReleaseFast usando /usr/bin/time -l.

Comando	RSS máx. médio 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

O Problema

Toda ferramenta de automação de navegador arrasta o Playwright (~300 MB), um runtime Node.js e uma cascata de dependências npm. Seu agente de IA só quer ler uma página, clicar em um botão e seguir em frente. Kuri é um único binário Zig. Quatro modos, zero runtime: