Cloudflare Web Search API: provedores, preços e a diferença de 28 vezes

O que a Cloudflare Web Search API realmente é

A apresentação no post de lançamento, de Michelle Chen, Sam Else e Gabriel Massadas, começa com uma admissão divertida. Quando um agente precisa de uma página ao vivo, ele geralmente chuta a URL e faz um curl, e é por isso que se veem tantos 404 nos logs de agentes. A busca na web dá ao agente um ponto de partida real: envie uma consulta, receba uma lista de resultados e passe-os ao modelo.

Por baixo, é uma camada de roteamento, não um mecanismo de busca. A página About da Cloudflare lista quatro etapas para cada solicitação:

1. Rotear a solicitação pelo AI Gateway que você indicar.
2. Encaminhar a consulta ao provedor escolhido, ou ao Ceramic.ai se você não escolheu nenhum.
3. Normalizar a resposta em um formato único: URL, título e, opcionalmente, descrição, imagem, favicon e data da última modificação.
4. Registrar a solicitação em log e cobrá-la na sua conta.

Esse é o produto inteiro hoje, e digo isso como elogio. Se você já faz chamadas de modelo pelo AI Gateway, a busca agora aparece nos mesmos logs, contra o mesmo orçamento, sob as mesmas regras de acesso. A Cloudflare também diz que as ferramentas de servidor estão chegando, então a busca na web acabará embutida no plano de controle, em vez de ser uma ferramenta que você conecta por conta própria.

O lançamento caiu na Birthday Week e claramente tocou num ponto sensível. O tópico no Hacker News chegou a 590 pontos e 284 comentários, mais do que o lançamento do navegador Kitesurf rendeu. O anúncio da própria Cloudflare no X recebeu uma resposta que resume por que as pessoas se importam:

"search in the same gateway as the model calls is the nice part. wiring exa into my agent tonight"

Avery Coree, X

Como uma solicitação se move por ela

Antes de falar de dinheiro, vale ver as partes móveis, porque toda decisão interessante está em uma delas.

Você pode chamá-la de duas formas, ambas documentadas na página de uso:

• REST: POST https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/websearch/, autenticado com um token de API da Cloudflare que tenha as permissões Workers AI Read e AI Gateway Read.
• Binding do Workers: env.AI.websearch({ gatewayId, query, provider, limit }), que retorna uma Response padrão na qual você chama .json().

A solicitação tem pouquíssimos ajustes, o que diz muito sobre o design:

Não há filtro de data, lista de domínios permitidos, parâmetro de país nem opção de "buscar a página inteira". Cada provedor roda em um modo fixo: o Exa usa o tipo de busca auto com trechos destacados como descrição, e o Linkup usa profundidade fast com resultados brutos, segundo a página de provedores. Se você precisar dos modos mais profundos do Exa ou do Linkup, chame-os diretamente.

A resposta é deliberadamente enxuta: um array items e um bloco metadata com sua consulta, um ID de solicitação e latencyMs. Essa leveza é o ponto. Ela entra direto na janela de contexto de um modelo sem que você escreva um parser por provedor, e a documentação da Cloudflare traz um exemplo completo de como conectá-la como ferramenta web_search para um modelo como o Gemma 4 rodando no Workers AI.

Por que o parâmetro de provedor é a verdadeira decisão de preço

Esta é a tabela que importa. Todos os números abaixo vêm da página de provedores da Cloudflare, conferida em 8 de outubro de 2026:

O Exa custa 28 vezes o que o Ceramic custa para o mesmo formato de solicitação, e trocar de um para outro é uma única string. Ótimo para experimentar e perigoso para orçamentos, porque nada no seu código muda quando alguém da equipe troca ceramic por exa num arquivo de configuração. Um comentarista do HN que postou a lista de preços fez a pergunta certa:

"Does anyone have insights on the quality differences? Web search API pricing for AI agent usecases has always felt so expensive for what it is, but I have no grounding on the economics of running a web index."

8bite, Hacker News

O post de lançamento da Cloudflare inclui uma captura de log que deixa o custo por busca bem concreto: uma única chamada exa/search cobrada a US$ 0,007, exatamente US$ 7,00 por 1.000.

A frase "sem acréscimo", lida com atenção

A Cloudflare diz que as buscas são cobradas "at each provider's list API price, with no additional markup." Isso é verdade por busca. Mas os créditos do AI Gateway vêm do Unified Billing, e essa página informa que uma taxa de 5% se aplica a todos os créditos comprados: uma recarga de US$ 100 é uma cobrança de US$ 105. Então, se você paga com créditos, sua tarifa efetiva fica cerca de 5% acima da tabela. Se você trouxer sua própria chave, o provedor cobra você diretamente e a taxa de créditos não vale para essas buscas.

Veja como isso fica em volumes reais, supondo uma busca por solicitação:

Os 5% são um erro de arredondamento perto da escolha do provedor. Com um milhão de buscas por mês, escolher Exa em vez de Ceramic é uma decisão de US$ 6.750 a preço de tabela; a taxa de créditos por cima é de no máximo US$ 350. Os agentes também raramente buscam uma vez só por tarefa. Um ciclo de pesquisa que dispara cinco buscas por pergunta do usuário transforma 200.000 perguntas em um milhão de buscas, e é assim que um recurso "barato" vai parar numa revisão financeira. Se quiser colocar seus próprios números, esta calculadora faz a multiplicação:

O que a Cloudflare normalizou e o que não normalizou

Este é o ângulo que acho que a maior parte da cobertura perde. A Cloudflare fez os três provedores parecerem idênticos no nível da API. Eles não são idênticos nos pontos que importam para uma equipe de produto.

Um post no X disse isso melhor do que eu conseguiria:

"The catch is that a unified endpoint also makes search providers look interchangeable when result quality, coverage, ranking, and failure modes probably won’t be."

Hero.S, X

Há três lacunas que vale conferir antes de colocar em produção.

A retenção de dados diz duas coisas diferentes

A entrada do changelog diz "all three support Zero Data Retention for requests made through Cloudflare." A página de provedores, atualizada no mesmo dia, lista o Exa como "Zero Data Retention: No." As duas páginas ainda diziam isso quando conferi em 8 de outubro. Um leitor do HN notou em poucas horas, e alguém da Exa respondeu:

"Thanks for raising this! We're looking into this discrepancy (I work at Exa)."

alexey-salmin, Hacker News

Até que coincidam, eu planejaria como se a tabela de provedores estivesse certa. Se suas consultas contêm nomes de clientes, números de pedido ou qualquer coisa de um ticket, isso faz do Ceramic ou do Linkup as escolhas mais seguras. Observe também que a configuração de ZDR do Unified Billing não controla o registro em log do AI Gateway; esse é outro interruptor.

O que você pode armazenar é definido pelos termos de cada provedor

A Cloudflare unificou o JSON. Não unificou a licença. Simon Willison levantou a pergunta que todo produto com um botão de "compartilhar este chat" deveria fazer:

"My number one question about search APIs is always if they allow you to store and resyndicate results you get from them."

simonw, Hacker News

Ele então citou os termos de serviço do Ceramic, que proíbem reter, fazer cache ou armazenar a saída além do que for "reasonably necessary to display such Output to your authorized end users in the ordinary and real-time course of use." Se seu agente grava resultados de busca em uma transcrição salva, uma base de conhecimento ou um cache, leia os termos do provedor que escolher. Exa e Linkup linkam seus próprios termos na mesma tabela de provedores.

A qualidade dos resultados não é um parâmetro

O provedor mais barato é o padrão, e a documentação descreve o Ceramic como feito para "low-latency, low-cost search." Os primeiros testadores acharam o índice dele irregular:

"Tried one query on ceramic.ai (the default provider for cloudflare web search api): "qwen-3.8 flash next and rtx 5090 best inference setup" ... 0 results ... same query on google and ddg both yield proper results."

freakynit, Hacker News

Uma anedota não é um benchmark, e o responsável pelo índice da Exa fez a ressalva justa, no mesmo tópico, de que a qualidade da busca varia conforme o tipo de consulta. Mas é um lembrete de que um conjunto de resultados vazio é um desfecho normal que seu agente precisa tratar, não um caso de borda. Mais sobre por que isso importa abaixo.

Web Search API versus outras formas de dar busca a um agente

A Cloudflare agora tem duas coisas chamadas "web search", o que confundiu alguns leitores. A página de busca web mais antiga do AI Gateway, atualizada em junho, trata do proxy da ferramenta de busca de cada fornecedor de modelos. A nova API é um produto separado.

Se você usa a API da Anthropic ou a API da OpenAI e está satisfeito com a busca embutida deles, as ferramentas nativas dão menos trabalho de integração. A Web Search API se justifica quando você roda modelos abertos, como o Kimi K3 ou os modelos por trás do DeepSeek Harness, que não têm parceiro de busca próprio. Um comentarista do HN chutou exatamente isso: os grandes agentes de programação vêm com parceiros de busca, e os modelos abertos precisam de busca de algum lugar.

Muitos desenvolvedores perguntaram "por que não chamar os provedores diretamente?" A resposta honesta do tópico é compras e orçamentos, não tecnologia. Um comentarista descreveu dar a um agente um único token da Cloudflare com limites de gasto, em vez de montar um proxy para cada serviço:

"Instead I put my API keys to cloudflare, set limits, and gave the agent the CloudFlare token, and in minutes it could contact tens of services."

bayesianbot, Hacker News

Isso bate com o que a Cloudflare documenta: limites de gasto por gateway, definidos por modelo, provedor ou metadados personalizados. Se sua equipe já paga a Cloudflare, adicionar busca é uma linha de orçamento, não uma nova avaliação de fornecedor. Se não paga, uma integração direta com a Exa ou com um scraper como o Firecrawl pode ser igualmente rápida. O cenário também está mudando sob os pés de todos: a Custom Search JSON API do Google está fechada a novos clientes, e os atuais têm até 1º de janeiro de 2027 para migrar.

Onde isso se encaixa para um agente de suporte e onde não

Meu viés, declarado de antemão. Trabalho com SEO há dois anos, e a primeira coisa que isso ensina é que a intenção de busca decide tudo. Um cliente perguntando "posso devolver isso depois de 30 dias?" não está perguntando à internet. Está perguntando a você. A fonte certa é a sua política de devolução, não os 10 primeiros resultados de "política de devolução de 30 dias".

Isso importa por causa de uma falha que vi de perto. Vi clientes pagantes da eesel cujo bot respondia a clientes reais com afirmações inventadas quando a recuperação da base de conhecimento voltava vazia; uma resposta tirou "Oxygen" da tabela periódica. A correção não foi mais busca. Foi um recurso de contingência rígido: quando suas próprias fontes não têm nada, passar a um humano em vez de deixar o modelo preencher a lacuna de onde conseguir. Uma API de busca web geral aumenta essa lacuna, não a diminui, porque agora o modelo tem a internet inteira de onde errar com confiança. Os padrões estão descritos no guia da eesel sobre alucinações de IA em suporte.

Então, para suporte, eu classificaria as fontes assim:

1. Sua central de ajuda, macros e tickets anteriores. É isso que a geração aumentada por recuperação para suporte deveria significar.
2. Seu próprio site e a documentação do produto, limitados ao seu domínio.
3. A web aberta, por último, para perguntas que são realmente sobre o mundo externo: uma queda de serviço de uma transportadora, uma regulamentação pública, o changelog de uma integração de terceiros.

A Cloudflare Web Search API é uma ferramenta razoável para esse terceiro grupo. Não substitui os dois primeiros, e a Cloudflare não a vende como tal.

Como a eesel se encaixa ao lado de uma API de busca

Busca na web é infraestrutura. A eesel é o funcionário. A Cloudflare dá ao seu agente uma forma de consultar coisas; a eesel dá a você um colega pronto para trabalhar que já sabe onde estão suas respostas. O colega de helpdesk com IA entra na sua fila atual em ferramentas como o Zendesk, aprende com sua central de ajuda e tickets anteriores, rascunha ou envia respostas e escala quando não tem uma resposta fundamentada. O time atual inclui também um redator de blog com IA para equipes de conteúdo.

Se você é do tipo de equipe que lê changelogs da Cloudflare por diversão, provavelmente vai gostar da CLI da eesel. Ela roda o mesmo colega a partir de um terminal, e tudo que você configura lá aparece no painel. Os comandos combinam bem com a ideia de "suas fontes primeiro":

• npx @eesel/cli init chat-bubble --site https://your-site.com cria um agente que começa a ler o seu próprio site, sem precisar de conta para um workspace de teste de 7 dias.
• eesel integrations connect website --url ... ou eesel integrations connect <platform> adiciona seu helpdesk ou sua documentação como conhecimento, e eesel files upload ./refund-policy.pdf adiciona uma política específica.
• eesel chat "what's our refund policy?" testa a resposta antes que um cliente a veja.
• eesel approvals lista as ações retidas para um humano, de modo que uma escrita que o agente quer fazer espera por aprovação.

Todo comando imprime JSON e todo erro volta com um hint, então um agente de programação como o Claude Code ou o Codex pode executar toda a configuração e ler os próprios resultados. eesel mcp token também transforma o workspace em um servidor MCP, que é como eu o conectaria a um agente que já usa a Cloudflare para busca. É o mesmo padrão que abordei em CLI para suporte ao cliente: um terminal, scripts e agentes controlando um mesmo colega.

Onde a eesel não é a escolha certa: se você está construindo um agente de pesquisa geral que vive de dados públicos da web, quer uma API de busca como a da Cloudflare, não um colega de helpdesk.

Meu veredito sobre a Cloudflare Web Search API

É um produto limpo, pequeno e honesto. Três coisas que eu faria antes de depender dele:

• Fixar o provider explicitamente, mesmo que você queira o Ceramic. Um padrão que você não escreveu é um padrão que alguém vai mudar sem perceber uma diferença de 28 vezes na fatura.
• Tratar a coluna de ZDR como indefinida para o Exa até que o changelog e a página de provedores coincidam, e ler os termos de armazenamento do provedor que você mantiver.
• Tratar resultados vazios de propósito. Retornar "não sei" ou passar a um humano, em vez de deixar o modelo improvisar. É o único hábito que impede que o grounding de IA vire alucinação de IA.

Se você já constrói na Cloudflare, é a forma mais fácil que já vi de dar busca ao vivo a um modelo aberto com uma fatura e um log. Se você está avaliando busca para um agente voltado ao cliente, comece com seu próprio conhecimento e adicione a web como último recurso. Para mais sobre a stack de agentes da Cloudflare, veja minhas notas sobre os modelos de decisão do Clef e as alternativas ao Kitesurf, ou explore o campo mais amplo dos mecanismos de busca com IA.

Experimente a eesel para respostas de suporte fundamentadas

Se o motivo de você olhar para uma API de busca web é que seu bot de suporte vive respondendo do nada, a solução costuma estar mais perto. O colega de helpdesk com IA da eesel aprende com sua central de ajuda, macros e tickets anteriores, e escala para sua equipe quando não tem nada fundamentado a dizer. Você pode testá-lo na sua própria base de conhecimento antes que ele toque num ticket ao vivo, e ver os planos na página de preços. Experimente a eesel de graça.