Kitesurf é grátis? Limites, preços e custos reais

Kitesurf é grátis? Sim, enquanto está em beta. Porém, a franquia realmente útil no Workers Free se limita a 10 minutos de navegador por conta ao dia, três Browser Sessions simultâneas e uma nova sessão a cada 20 segundos. Isso basta para um piloto bem dimensionado, não para provar que toda a sua pilha de agentes não custa nada.

Kitesurf é grátis durante o beta?

O Kitesurf é grátis enquanto o navegador está em beta. A Cloudflare afirma isso diretamente na atualização de 28 de setembro de 2026, mas faz uma ressalva igualmente importante: o acesso está sujeito aos limites do Browser Run por conta.

Kitesurf é o mecanismo de navegador sem estado da Cloudflare para agentes de IA. Ele roda no Workers e troca recursos voltados a usuários humanos por um ambiente de execução mais enxuto, pensado para agentes. Hoje não há cobrança separada pelo mecanismo Kitesurf, mas o Browser Run continua sendo o medidor ao redor dele.

Os limites atuais do Browser Run e os preços do Browser Run criam quatro fronteiras que vale a pena comparar lado a lado:

Portanto, “grátis” é uma resposta útil sobre o produto, mas incompleta para o orçamento. Ela informa quanto a Cloudflare cobra pelo Kitesurf durante o beta. Não diz se o fluxo de trabalho cabe nas cotas da conta, se será preciso adotar o Workers Paid nem quanto custará o modelo usado pelo agente.

Os preços e limites deste guia foram conferidos nas páginas públicas da Cloudflare em 29 de setembro de 2026. Como não havia um job autenticado do Browser Run disponível para esta análise, não há aqui fatura de painel inventada, resultado fictício de tempo decorrido nem taxa de sucesso fabricada para chamadas de ferramenta.

O que realmente mudou em 28 de setembro de 2026

A atualização de setembro tornou o Kitesurf mais viável para pilotos mais amplos porque conectou o mecanismo às interfaces que desenvolvedores de agentes já utilizam. O lançamento original, em agosto, apresentou o navegador. Esta atualização acrescentou as camadas práticas ao redor dele.

Primeiro, o Kitesurf agora oferece suporte ao WebMCP, uma API de navegador pela qual um site expõe ferramentas nomeadas com entradas estruturadas. Assim, um agente pode chamar uma função no estilo searchFlights() em vez de tentar deduzir botões a partir de pixels. A documentação do WebMCP da Cloudflare informa que o Kitesurf consegue listar e executar essas ferramentas pelo Chrome DevTools Protocol, normalmente abreviado como CDP.

Segundo, o Kitesurf passou a ter cobertura completa da API do Browser Run. Ele pode ser selecionado por CDP, Playwright, Puppeteer ou MCP. As Quick Actions — interfaces de uma única requisição da Cloudflare para screenshots, HTML, PDFs e outros resultados comuns — também podem selecionar o Kitesurf em um Worker por meio de env.BROWSER.quickAction().

Terceiro, o renderizador pode funcionar em terminais compatíveis pelo protocolo gráfico Kitty, além de oferecer um modo de texto ANSI puro quando o Kitty não está disponível. Isso ajuda a enxergar a página do ponto de vista do navegador do agente sem abrir outro navegador no desktop. É um recurso de inspeção, não uma nova faixa de cobrança para produção.

A Cloudflare também informa, na atualização de setembro, que o Kitesurf agora passa em mais de 730,000 subtestes do Web Platform Tests, mais de 500,000 além do resultado no lançamento. É um avanço relevante de compatibilidade, mas não garante que qualquer portal de cliente será renderizado corretamente. Por isso, o piloto ainda precisa trabalhar com uma lista delimitada de sites.

Limites do Kitesurf beta: cabem dez tarefas por dia?

Dez tarefas diárias só cabem na franquia se cada tarefa completa consumir, em média, no máximo 60 segundos de navegador. A franquia do Workers Free é de 10 minutos, ou 600 segundos de navegador. Dividindo esse orçamento por 10 tarefas, o limite fica em 60 segundos por tarefa.

A fórmula útil é daily task ceiling = floor(600 / measured browser seconds per task). Não substitua essa medida pelo tempo decorrido registrado no log da aplicação. Nas Quick Actions, a Cloudflare retorna o tempo de navegador no cabeçalho de resposta X-Browser-Ms-Used, de acordo com sua documentação de preços. Registre esse valor para a mesma tarefa e os mesmos sites de destino que entrarão em operação.

O tempo não é o único limite. A página de limites informa que uma conta Free pode manter três Browser Sessions simultâneas, iniciar uma nova sessão a cada 20 segundos e fazer uma requisição de Quick Actions a cada 10 segundos. O tempo limite padrão por inatividade é de 60 segundos. A Cloudflare permite uma janela keep_alive maior nas integrações de sessão compatíveis, mas a página do WebMCP informa que o Kitesurf não aceita keep_alive na configuração MCP do Chrome DevTools.

A mesma página de limites estabelece outra barreira do plano Free para /crawl: cinco jobs de rastreamento por dia e no máximo 100 páginas em cada rastreamento. Um agente de pesquisa que transforma uma pergunta em vários rastreamentos pode esgotar a quantidade de jobs muito antes de consumir os 10 minutos de navegador.

A disciplina ao encerrar sessões também altera a capacidade. A Cloudflare alerta que uma sessão deixada aberta continua consumindo tempo de navegador até expirar. Um encerramento explícito registra NormalClosure; o fim por inatividade registra BrowserIdle. Coloque browser.close() em um bloco finally e depois confira o motivo do encerramento, em vez de presumir que o código fez a limpeza.

A regra de decisão é direta: se a mediana medida ficar em 60 segundos ou menos e os limites de taxa não enfileirarem o trabalho, um piloto de 10 tarefas cabe na franquia. Caso contrário, reduza o conjunto de páginas ou o escopo da tarefa antes de pagar para escalar um ciclo ineficiente.

Preço do Kitesurf na Cloudflare: três limites de custo

O preço não se resume a um número, porque Kitesurf, conta do Workers, uso do Browser Run e modelo de raciocínio são serviços distintos. Juntar tudo em uma única linha de “agente grátis” esconde qual será a primeira cobrança a aumentar.

O custo bruto excedente do navegador hoje é pequeno para uma tarefa curta. Pela tarifa publicada do Browser Run, depois das 10 horas incluídas no Workers Paid, uma tarefa de 60 segundos custa $0.0015 à tarifa de $0.09 por hora, antes de simultaneidade, computação do Workers, uso do modelo ou cobrança de um SaaS externo. As mesmas 10 horas incluídas comportam 600 tarefas de navegador com um minuto cada, se o trabalho tiver duração uniforme.

Essa conta não deve virar uma promessa sobre o Kitesurf após o beta. A Cloudflare não publicou uma tarifa específica para o Kitesurf pós-beta na atualização, na documentação do produto, na página de preços do Browser Run nem na página de preços do Workers. O mínimo de $5 do Workers Paid compra o plano da conta Workers. Não fixa o preço futuro do Kitesurf.

Para quem compra, o orçamento mais claro separa tempo de navegador, simultaneidade de sessões, Workers, modelo e qualquer sistema pago acessado pelo agente. Um mecanismo de navegador gratuito ainda pode fazer parte de um fluxo de trabalho pago.

Kitesurf no Browser Run: o impacto para desenvolvimento, operação e compra

A plataforma está pronta para trabalhos sem estado e de escopo bem definido, não para substituir o Chromium em qualquer cenário. As consequências mudam conforme o papel de cada equipe.

Desenvolvimento: use a menor interface que conclui a tarefa

Comece com uma Quick Action quando o resultado necessário for um screenshot, o conteúdo de uma página, um PDF ou uma extração estruturada. Adicione browser=kitesurf ao endpoint, meça o tempo de navegador retornado e só passe para uma sessão completa quando o trabalho exigir navegação ou estado ao longo de várias ações.

O WebMCP é atraente quando um site compatível expõe exatamente a ação necessária ao agente. Ele troca um ciclo visual frágil por uma ferramenta nomeada. Ainda assim, é preciso validar a implementação do site, os limites de permissão e o resultado.

Quando uma sessão voltada a clientes se aproximar da produção, combine a escolha do mecanismo com os controles do Browser Run. O guia existente sobre hosts aprovados e revisão de clientes somente leitura trata do limite de destinos que a escolha de navegador, sozinha, não oferece.

Operação: meça separadamente o trabalho normal e as falhas

Registre o tempo de navegador em milissegundos, o motivo do encerramento, o resultado da requisição e o uso do modelo para cada classe de tarefa. Uma extração bem-sucedida e uma página que expirou não representam a mesma carga de trabalho. Colocá-las na mesma média esconde se o ajuste necessário está no navegador, no site ou no ciclo do agente.

Em jobs com falha, preserve as evidências antes de iniciar outra execução. O fluxo de inspeção do Browser Run pode mostrar console, rede e estado final da página depois de uma sessão gravada. O guia para depurar um job com falha antes de executá-lo novamente explica quando essas evidências valem mais do que uma nova tentativa imediata.

Compra: adquira capacidade só depois de validar a compatibilidade

Não faça upgrade apenas porque o contador do plano Free chegou ao limite. Primeiro, confirme que o Kitesurf renderiza os sites de destino e conclui a tarefa corretamente. Depois, identifique se o gargalo está no tempo diário de navegador, na taxa de requisições, na simultaneidade ou no modelo.

A documentação atual da Cloudflare deixa clara a divisão entre os mecanismos. Escolha o Kitesurf para renderização única, extração e trabalhos de agentes sem estado, em rajadas e compatíveis com ele. Escolha o Chromium quando o fluxo exigir vídeo, WebGL, um handshake de desafio antibot com fingerprints TLS reais ou uma sessão autenticada longa com estado persistente.

A decisão pode ser tomada antes de uma adoção ampla: uma tarefa representativa, um conjunto de sites de destino, uma distribuição medida do tempo de navegador e um fallback explícito. Se o fallback for acionado com frequência, o mecanismo mais enxuto não estará reduzindo o custo operacional.

Quem deve agir agora, quem deve esperar e quem não será afetado

Aja agora se você cuida de um fluxo de suporte, pesquisa ou QA baseado em páginas públicas ou de baixo risco. Bons pilotos incluem capturar um screenshot da central de ajuda, extrair uma nota de versão, conferir um componente renderizado ou chamar uma ferramenta de busca WebMCP em um site compatível. São tarefas curtas, auditáveis e fáceis de comparar com um resultado conhecido.

Espere se o fluxo depender de login persistente, vídeo, WebGL, compatibilidade com desafios antibot ou confirmação autônoma de ações sensíveis do WebMCP. As sessões do Kitesurf não aparecem em wrangler browser list e não oferecem visualização ao vivo. Segundo a Cloudflare, uma sessão de agente no Kitesurf não consegue concluir uma ferramenta que pausa para confirmação humana; essa interação exige o playground manual.

Também espere antes de assumir um compromisso orçamentário que ultrapasse o beta. O navegador é grátis hoje, mas não existe preço publicado para o Kitesurf pós-beta que possa entrar em um contrato longo ou em uma proposta de valor fixo para clientes.

Você praticamente não será afetado se um fluxo estável no Chromium Browser Run já cumpre as metas de custo e confiabilidade. A versão de setembro oferece outro backend para avaliar, mas não torna obrigatória a migração de um navegador de produção que já funciona.

O que há de exagerado no beta grátis

A palavra “grátis” está sendo esticada demais quando descreve o agente inteiro. Ela cobre a disponibilidade do Kitesurf durante o beta, não o modelo, o tempo da equipe de operação, o SaaS de destino nem um preço comercial futuro.

O WebMCP também não acaba com as falhas de navegador. A Cloudflare documenta quatro lacunas relevantes na implementação atual do Kitesurf: não há política de permissão nem filtragem de origem para ferramentas WebMCP; ferramentas em iframes ou pop-ups não são expostas por CDP; sessões do Kitesurf não têm visualização ao vivo; e o agente não consegue confirmar ferramentas que exigem a presença de uma pessoa. Uma função nomeada só é mais confiável do que clicar em pixels quando a página expõe e protege a função correta.

O renderizador no terminal oferece visibilidade, não uma estratégia de implantação. Ele ajuda quem desenvolve a inspecionar o que o Kitesurf enxerga, mas não altera minutos de navegador, simultaneidade, custo do modelo ou compatibilidade com sites.

A história de desempenho exige a mesma cautela. No benchmark de mediana da própria Cloudflare, realizado com cinco execuções de Quick Action em um corpus de 14 URLs, o Kitesurf consumiu 380 ms de CPU para um screenshot, contra 1,173 ms do Chromium em warm pool, e 57.8 MiB de memória, contra 271.0 MiB. Também foi mais lento no tempo decorrido: 1,148 ms contra 637 ms. Usar menos recursos é valioso em escala, mas isso não significa que toda requisição isolada termine mais rápido.

Por fim, passar em mais de 730,000 subtestes indica progresso rápido, não paridade com toda a web. Uma matriz de compatibilidade criada a partir dos seus sites de destino ainda vale mais do que uma contagem global de testes.

O próximo passo na segunda-feira: rode um piloto controlado

O passo certo agora é um teste controlado na conta, não uma migração de arquitetura. Esta página não executou uma requisição autenticada do Browser Run; portanto, a sequência abaixo é um piloto reproduzível, não um benchmark apresentado como experiência própria.

1. 1

   Inspecione a interface pública

   Abra o playground do Kitesurf no Cloudflare Radar. No DevTools, abra Application > WebMCP e registre as ferramentas que, segundo a Cloudflare, o Radar expõe, entre elas navigate-to e set-location. Não trate a presença dessas ferramentas como prova de que seu site de destino oferece equivalentes.

2. 2

   Execute uma tarefa representativa

   Use uma conta de teste existente para uma requisição de conteúdo ou screenshot. O formato de screenshot documentado pela Cloudflare é:

   curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
     -H 'Authorization: Bearer <API_TOKEN>' \
     -H 'Content-Type: application/json' \
     -d '{"url":"https://example.com"}' \
     --output screenshot.png

   Comece por um destino não sensível. Confirme se o resultado está correto antes de otimizar a velocidade.

3. 3

   Registre todos os limites de custo

   Anote o plano Workers, o X-Browser-Ms-Used de uma Quick Action, o uso do Browser Run, o motivo do encerramento da sessão e o uso do modelo. Em uma Browser Session, encerre explicitamente e confirme NormalClosure, não BrowserIdle.

4. 4

   Calcule a franquia

   Divida 600 pelos segundos de navegador medidos por tarefa bem-sucedida e arredonde para baixo. Um dia com 10 tarefas exige média medida de 60 segundos ou menos. Mantenha a cobrança do modelo em uma coluna separada e então decida se o piloto cabe no Free, precisa de uma tarefa mais enxuta ou justifica o Workers Paid.

Essa única execução entrega as evidências que faltam: compatibilidade, tempo de navegador, comportamento no encerramento e custo do modelo para uma tarefa que a empresa realmente repetiria.

Se quiser transformar a próxima mudança de preço ou limite na infraestrutura de agentes em uma decisão operacional concreta, assine a newsletter.