justrach/kuriAutomação de navegador, rastreamento web e controle de dispositivos iOS + Android para agentes de IA. Snapshots de CDP nativos em Zig e eficientes em tokens, gravação de HAR, cliente nativo do protocolo de rede adb e um fetcher independente.
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
ReleaseFastpara 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 dokuri-agent(go→snap→click→snap→eval). Deltas entre ferramentas devem ser reexecutados no mesmo ambiente antes de citar uma porcentagem.
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.
@eN e renderização sem prefixo./page/state (48 tokens) vs snapshot completo (2.124 tokens) para a mesma página do Google Flights.POST /batch envia N comandos em uma única chamada HTTP, eliminando N-1 round-trips e N-1 turnos do LLM.onClick e onChange do React 18/19.SIN → TPENova 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] |
| 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:
@e0 (3 chars) vs [ref=e0] (9 chars)- por linha (economiza 2 chars × número de linhas)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) |
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 detiktoken. Reexecute os números entre ferramentas no seu próprio ambiente antes de citar uma porcentagem.
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) |
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 |
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: