6 de agosto de 2026, a Cloudflare lançou Kitesurf — um navegador, escrito não para pessoas, mas para agentes. Não há Chromium por dentro: o motor é construído em Rust, compilado em WebAssembly e funciona totalmente em isolados V8 em Workers. A empresa afirma que em tarefas típicas de agentes, ele consome de 3 a 7 vezes menos CPU e memória do que o Chromium. Quatro meses antes, o open source Obscura — também Rust, também "para agentes" — acumulou mais de 22 mil estrelas no GitHub, e a Cloudflare reconheceu abertamente que o primeiro protótipo do Kitesurf foi um port do Obscura para Workers.
O mercado de motores para automação se dividiu: de um lado — runtimes leves para agentes, que economizam recursos; do outro — compilações pesadas do Chromium, que conseguem tudo, incluindo passar por verificações anti-bot. Vamos analisar os fatos, o que cada classe realmente oferece e onde termina a economia.
Quais critérios usar para comparação
Benchmarks de motores gostam de medir velocidade e memória, mas para scraping em combate e agentes, quatro eixos independentes são importantes, e a vantagem no primeiro não diz nada sobre os outros:
- Custo de inicialização — CPU e memória por página. Isso se traduz diretamente na conta de infraestrutura com milhares de sessões paralelas.
- Completude da plataforma web — quantos sites modernos renderizam corretamente. Aqui se mede pela cobertura dos Web Platform Tests (WPT).
- Passagem por anti-bot — a sessão sobreviverá ao handshake TLS, desafio JS e verificação comportamental.
- Controle de saída de rede — você pode gerenciar de qual IP e ASN o site vê a solicitação.
Kitesurf: economia versus completude
Kitesurf é construído a partir de módulos: renderização e análise de HTML/CSS em Blitz, motor CSS Stylo do Firefox, runtime JS Boa em Rust, e formatação de texto através do Parley. O desenvolvimento levou, segundo a empresa, 12 semanas.
Números do benchmark próprio da Cloudflare contra o Chromium:
- CPU por screenshot — 380 ms contra 1173 ms (3,1 vezes menos);
- CPU por extração de HTML — 229 ms contra 877 ms (3,8 vezes menos);
- memória por screenshot — 57,8 MiB contra 271 MiB (4,7 vezes menos);
- memória por extração de HTML — 39,4 MiB contra 273,7 MiB (7 vezes menos);
- mas em termos de tempo de execução, Kitesurf é mais lento: 1148 ms contra 637 ms no screenshot e 820 ms contra 472 ms no HTML — de 1,7 a 1,8 vezes.
É uma troca honesta: você paga com latência, mas ganha a capacidade de manter muito mais sessões paralelas em uma única máquina. De acordo com os padrões web, o motor se mantém razoavelmente bem para sua idade — no momento do anúncio, cerca de 215 mil testes WPT foram concluídos, e a documentação agora afirma mais de 235 mil. Cobertura por seções: DOM 97%, HTML 96%, Selection 99%, SVG 97%, Encoding 99%, CORS 95%, XHR 95%, URL 83%. Wikipédia, Hacker News e SPAs típicas são renderizadas.
O Kitesurf se conecta de forma familiar: endpoint CDP (o que significa Puppeteer e Playwright), MCP para agentes, endpoints REST Quick Actions para screenshot e extração de HTML. Basta adicionar o parâmetro browser=kitesurf. A beta é gratuita, mas com limites por conta; a empresa promete abrir o código-fonte.
O que Kitesurf não consegue — e isso está escrito em sua própria documentação
A lista de limitações é curta, mas abrange toda a linha de defesa dos sites modernos. O Kitesurf não suporta:
- reprodução de vídeo;
- renderização WebGL;
- handshake de bot-challenge com impressões TLS reais;
- sessões autorizadas longas que requerem estado constante.
O terceiro ponto é crucial. A Cloudflare escreve: se a tarefa esbarra em um bot-challenge, use o Chromium comum no Browser Run. Ou seja, a empresa que impõe esses desafios em milhões de sites avisa honestamente que seu próprio navegador leve não os supera. Isso não é uma falha da beta, mas uma consequência da arquitetura: a impressão TLS (JA3/JA4) é gerada na pilha de rede, e não no renderizador, e o motor Rust no isolado Workers é fisicamente diferente do verdadeiro Chrome.
Um efeito colateral do motor não convencional é a singularidade. Scripts anti-bot foram calibrados por anos em artefatos do Chromium: ordem das propriedades, especificidade dos erros, tempos de API. Um motor que não possui esses artefatos não parece "mais limpo" — ele parece diferente, e "diferente" em scoring anti-bot custa mais do que "como todos". Já discutimos esse efeito na análise dos navegadores stealth de 2026: benchmarks de pureza de JS fingerprint e resultados em alvos reais divergem, porque alvos reais consideram a soma de sinais.
Obscura: a mesma classe, mas no seu servidor
Obscura é o representante open source principal da classe. O repositório foi criado em 13 de abril de 2026, licença Apache-2.0, e no final de agosto — mais de 22 mil estrelas. Por dentro, um verdadeiro V8, por fora — CDP, ou seja, também uma substituição drop-in para o headless Chrome para Puppeteer e Playwright.
A decisão arquitetônica chave: o Obscura não tem um pipeline de layout e renderização, ele não renderiza a imagem de forma alguma. Daqui, os números do benchmark do autor — a mediana em 33 cenários dá aproximadamente 21 vezes a velocidade e cerca de um sétimo da memória em relação ao headless Chrome. Em carga contínua de páginas React em quatro workers, isso resulta em 40 páginas por segundo com 112 MB de memória contra 3 páginas por segundo com 4,2 GB no Chrome. A cobertura WPT no "núcleo" (DOM, HTML, URL, fetch) é de 83,3%, ou seja, 318.916 testes de 382.891.
A diferença prática com o Kitesurf não está na velocidade, mas em onde tudo isso roda. O Obscura você implanta por conta própria — e decide por si mesmo por qual saída de rede ele passa. O Kitesurf vive na rede de outra pessoa, e isso nos leva ao ponto principal.
Quem controla seu IP de saída
Sobre a economia de CPU, todos escreveram, sobre a saída de rede — quase ninguém. No entanto, o Kitesurf é executado em Workers, o que significa que as solicitações saem da rede da Cloudflare, com seu ASN. Não há controle sobre o IP de saída ou a conexão de um proxy próprio na documentação do Kitesurf. No Browser Rendering vizinho, os desenvolvedores enfrentam o mesmo: a tentativa de definir um proxy upstream através de proxyServer no BrowserContext falha com net::ERR_PROXY_CONNECTION_FAILED, e endereços egressos fixos para Workers não são normalmente previstos.
Para o cenário alvo da Cloudflare, isso é aceitável: o agente navega por páginas abertas, tira screenshots, extrai HTML. Mas assim que o alvo está um pouco protegido, você obtém a pior combinação possível de sinais:
- O IP pertence a um grande ASN de nuvem, ou seja, é claramente marcado como servidor;
- A impressão TLS não coincide com nenhum navegador real;
- Você não pode substituir nenhum dos dois, porque não controla nem a pilha de rede, nem a saída.
Essa situação explica por que a conversa sobre agentes em 2026 está cada vez mais se afastando da otimização do runtime e se concentrando na questão do acesso legal e pago — desde agentes assinados até solicitações pagas, sobre as quais escrevemos na análise de carteiras para bots e HTTP 402. Se o site não o permite, o motor mais econômico do mundo não ajudará: você simplesmente não consegue uma página que não foi entregue a você.
O que escolher para a tarefa
Kitesurf — quando os alvos são abertos e há muitos deles: monitoramento de páginas públicas, extração de HTML para índice RAG, screenshots em massa, contornos de documentação de agentes baratos. Além disso, beta gratuita e nenhuma complicação com infraestrutura. Não o use onde há login, anti-bot ou exigência de geolocalização específica.
Obscura — o mesmo perfil de carga, mas quando o controle é necessário: seu próprio hosting, sua saída de rede, seus patches. Serve como um trabalho pesado em um parque de parsing, onde o custo da página é importante, e a aparência da página não importa. Funciona bem com proxies, porque você controla todo o processo.
Chromium comum sob Playwright ou Puppeteer — quando vídeos, WebGL, sessões autorizadas complexas e renderização real são necessários. Caro em recursos, mas previsível.
Compilações stealth do Chromium (Camoufox, nodriver, patchright, e das mais recentes — CloakBrowser, que acumulou mais de 30 mil estrelas desde fevereiro de 2026) — quando o alvo está protegido e não há outras opções. Os recursos são um pouco mais altos do que os do Chromium puro, mas o principal é mantido: uma pilha de rede real, na qual você pode inserir a saída necessária.
E um denominador comum para as três últimas opções: o motor decide como você aparece no nível do navegador, e proxies residenciais decidem como você aparece no nível da rede. Para alvos abertos e tarefas internas, endereços de data center são suficientes — eles são mais baratos e mais rápidos. Para plataformas com proteção real, o custo da página não é calculado em megabytes de memória, mas pela proporção de respostas bem-sucedidas.
Conclusão
Kitesurf e Obscura são uma resposta honesta e, segundo os números, bem-sucedida para uma dor real: usar o Chromium para extrair HTML é realmente desperdício, e o relatório da Apify e do The Web Scraping Club confirma isso — 65,8% dos especialistas em 2025 usaram mais proxies do que no ano anterior, e 58,3% aumentaram o orçamento para eles. Os gastos com automação estão crescendo, e a economia de 3 a 7 vezes em memória é um argumento significativo.
Mas a economia funciona exatamente até o primeiro alvo protegido. O motor leve não supera o bot-challenge — isso está escrito na documentação da própria Cloudflare. O runtime em nuvem não permite controlar o IP de saída. Portanto, a pilha de agentes de 2026 é composta por duas camadas independentes: um motor barato para páginas abertas em massa e um navegador completo com saída de rede controlada para tudo o mais. Tentar fechar ambas as camadas com uma única ferramenta resulta em pagar demais pelo Chromium onde bastaria o Rust, ou em uma conversão nula do parser onde faltou IP.
```