Cloudflare Web Search API entered open beta on 2 October 2026, adding live web search to AI Gateway. Developers can now give agents and AI applications current web results through one interface instead of building separate integrations for each search provider.

The service launches with Ceramic.ai, Exa and Linkup. Cloudflare presents them through the same response structure, while search requests appear alongside model traffic in AI Gateway logs and can use the same billing and access-control layer. For small development teams, that makes web grounding easier to operationalise, but provider quality, cost and privacy still need to be evaluated deliberately.

What Cloudflare Web Search API adds

Web Search API lets an application send a search query and receive structured results containing titles, URLs and descriptions that can be placed directly into model context. It can be called through a REST API from any backend or through the AI binding in Cloudflare Workers.

The key design choice is provider abstraction. A developer selects Ceramic.ai, Exa or Linkup with a single provider parameter, but the application receives results in a common format. That makes it possible to change search providers without rewriting the rest of the agent workflow.

If no provider is specified, Cloudflare uses Ceramic.ai by default. Cloudflare says all three launch providers support Zero Data Retention for requests made through the service and have committed to its verified bot crawling requirements.

Why this matters for AI agents

Many agent workflows fail when they rely only on model training data or try to fetch guessed URLs. A model may know that a document probably exists but still invent the exact location, follow an outdated address or miss a recent update.

Search changes that workflow. The agent can first retrieve current sources, then decide which pages are worth reading. This is particularly useful for research, monitoring, support systems, current product information and any task where freshness matters.

The approach also fits the broader trend towards treating AI infrastructure as a set of interchangeable services. Nevelit’s article on AI model routing and Cloudflare’s cost-quality trade-off examined the same principle for model selection. Web Search API applies a similar idea to retrieval: the application can choose between providers without changing its entire architecture.

Three providers, different cost and retrieval models

Cloudflare’s current provider documentation shows a wide pricing spread. Ceramic.ai is listed at $0.25 per 1,000 requests, Linkup at $5 per 1,000 and Exa at $7 per 1,000 when paid through AI Gateway credits. Cloudflare says it adds no markup to the provider’s list API price.

The providers are not identical. Ceramic.ai uses its own large web index and returns relatively long page descriptions. Exa uses its search API in an automatic mode and returns query-relevant highlights. Linkup uses its fast search depth and returns raw search results rather than generating an answer.

An independent comparison published on the launch date reached the same practical conclusion: search APIs for agents vary substantially in price and limits, so the cheapest provider is not automatically the best choice for every workload. Coverage, latency, result quality and the amount of useful text returned all affect total system cost.

Observability may be as important as the search itself

Because the new API runs through AI Gateway, search activity appears in the same observability environment as model requests. Teams can see search calls in logs and analytics instead of treating retrieval as a separate black box.

That is useful when an agent becomes expensive or unreliable. A developer can investigate whether the problem is caused by excessive searches, poor search results, too much retrieved context or the model that receives the results.

Cloudflare also supports bring-your-own-key arrangements. In that case, the search provider bills the customer directly under its own agreement, while Cloudflare remains the integration layer.

Web Search API is not the same as Cloudflare AI Search

The product names are easy to confuse. Web Search API searches the public web through external search providers. Cloudflare AI Search is a separate managed retrieval product for content that a customer indexes, such as documentation, websites or files.

AI Search became generally available on 1 October 2026 with hybrid search enabled by default for new instances, multimodal embedding support and OCR for scanned PDFs. Web Search API, by contrast, is still in open beta and is designed to bring live Internet search into agents and applications.

A project may use both. An assistant could search private company documentation through AI Search and use Web Search API when it needs current public information.

Practical questions before adopting it

  • Do you actually need live search? Static internal workflows may be better served by indexed private data than repeated public web queries.
  • Which provider matches the task? Compare result quality and latency, not only the headline request price.
  • How much context will you pass to the model? Cheap search can still create expensive inference if every result is inserted into a large prompt.
  • What should be logged? Search queries can contain sensitive business context, even when the provider supports Zero Data Retention.
  • How will you verify sources? Search grounding improves freshness, but retrieved pages can still be wrong, outdated or low quality.

Trade-offs and limitations

The main advantage is simplification: one API, multiple providers, shared logging and centralised billing. That lowers the integration burden for small teams experimenting with agentic workflows.

The abstraction can also hide meaningful differences between providers. Two services may return the same schema while producing very different results for the same query. Teams should benchmark real workloads rather than assume that provider switching is operationally neutral.

Open beta status is another consideration. Interfaces, limits and commercial terms can change before general availability. Systems that depend heavily on the service should isolate the search layer so a provider or API change does not require a broader rewrite.

Critical analysis

Cloudflare Web Search API is most compelling as an infrastructure product rather than a new search engine. Its value comes from putting live retrieval behind the same control plane teams may already use for model traffic.

For small businesses, that can remove a surprising amount of plumbing: separate search credentials, different response formats, isolated logs and provider-specific code. The risk is assuming that technical unification also means provider equivalence. It does not.

The sensible adoption path is to test two or more providers on the same real queries, measure result usefulness and total downstream token cost, then choose based on the workload rather than price alone. Live search can make agents more current and grounded, but it still needs source evaluation, logging discipline and cost controls.

Sources


Leave a Reply

Your email address will not be published. Required fields are marked *