Cloudflare has added a Web Search API beta to AI Gateway, widening the gateway from model inference into the external tools that AI applications increasingly call alongside models. The new API, announced on October 2, lets developers send search requests through the same Cloudflare AI Gateway layer used for provider routing, logging, and billing visibility.
At launch, the Web Search API supports Ceramic.ai, Exa, and Linkup. Cloudflare’s provider documentation lists Ceramic.ai as the default provider and shows provider-level prices of $0.25 per 1,000 requests for Ceramic.ai, $7.00 per 1,000 requests for Exa, and $5.00 per 1,000 requests for Linkup. Cloudflare says requests are billed to AI Gateway credits at the provider list price, with no additional markup.
The practical change is not only that Cloudflare customers can call a search API. Many teams already use web search, retrieval APIs, browser tools, or custom crawlers somewhere in their agent stack. The change is that search is being pulled into the same administrative layer as model calls. For teams building agents, research assistants, compliance workflows, sales-enrichment tools, or support systems, live search now becomes gateway traffic rather than a separate integration with separate logs and invoices.
What changed
Cloudflare AI Gateway has been moving beyond simple request proxying into a broader multi-model AI API gateway layer. Recent gateway features have focused on model routing, provider billing choices, and observability for LLM requests. Web Search API extends that control surface to grounding calls: the API can route to supported search providers while recording requests in AI Gateway logs.
That matters because retrieval and web grounding are now part of production AI cost and reliability, not an optional add-on. A customer-support agent may use a model for reasoning, a search provider for current information, and a database or SaaS API for private context. If those calls are governed separately, engineering and finance teams lose a clear view of the full cost of a workflow. By placing search behind AI Gateway, Cloudflare is treating search as another managed dependency in the AI request path.
The launch also gives developers a normalized starting point for provider comparison. Ceramic.ai, Exa, and Linkup differ in price, index behavior, and product positioning. A gateway layer does not remove those differences, but it can make them easier to observe and swap during testing. The most visible example is pricing: based on Cloudflare’s listed provider rates, Exa is far more expensive per 1,000 requests than Ceramic.ai, while Linkup sits between them. For high-volume agent workloads, that spread can be material.
Why businesses should care
For businesses, the Web Search API is part of a larger shift from single-model API integration toward an AI API control plane. The operational question is no longer just which model produces the best answer. It is which model, search provider, retrieval path, and tool sequence should be allowed for a given team, customer, geography, or data class.
Live web search creates a specific governance challenge. Unlike a static model call, a search request can expose query text to a third-party provider and return web content with uncertain reliability, licensing, or policy characteristics. The search provider can also influence the final model answer by controlling which sources are surfaced. That means provider selection is both a cost decision and a risk decision.
Cloudflare’s logging integration helps with auditability. If search requests appear in AI Gateway logs, teams can inspect which applications are grounding answers on the open web, how frequently they call each provider, and where costs are accumulating. That is useful for security review, incident analysis, and LLM cost management, especially when agents make multiple tool calls per user request.
The no-markup billing claim is also relevant. Gateway products often create a tradeoff between operational convenience and pricing opacity. Cloudflare is positioning Web Search API as provider-list-price usage billed through AI Gateway credits. Teams will still need to validate their own effective costs, discounts, and credit accounting, but the public structure makes search spending easier to model than a bundled or undisclosed markup system.
Developer impact
Developers building agentic systems should treat this as a new tool surface, not just another HTTP endpoint. Search calls need provider selection, timeout handling, result filtering, retry policy, and attribution in logs. A search API that runs through a gateway can simplify some of that plumbing, but it does not remove the need to design the agent’s retrieval behavior carefully.
The immediate opportunity is cleaner experimentation. A team can test Ceramic.ai, Exa, and Linkup through the same gateway path and compare cost, latency, answer quality, and source coverage under real workloads. That is more useful than comparing provider demos in isolation. It also makes it easier to decide when search is worth using at all. Some workflows may only need cached documentation or an internal knowledge base; others need fresh web results and can justify the added cost.
The feature may also affect platform teams that run shared AI infrastructure for multiple product groups. If one team is building a lightweight classification workflow and another is building a browsing research assistant, their search usage profiles will be very different. Centralized gateway logs give platform owners a better chance of assigning spend, detecting runaway tool loops, and setting policy boundaries around which providers can be used in production.
What remains uncertain
The main uncertainty is provider-level data handling. The research package notes an apparent discrepancy between Cloudflare’s changelog and provider documentation on Exa Zero Data Retention status. Teams in regulated industries should verify retention terms directly before sending sensitive queries through any search provider, even when the request is routed through a gateway.
Quality is another open question. Search-provider performance depends heavily on query type, freshness requirements, domain coverage, ranking behavior, and how the downstream model uses retrieved snippets. The beta gives developers a convenient way to test, but it does not establish that one provider is best for all agent workloads.
Still, the direction is clear: AI gateways are expanding from model access into the surrounding services that make AI applications useful. Search, routing, billing, and observability are becoming parts of the same stack. For businesses, that makes gateway architecture less about saving a few integration hours and more about maintaining control over a growing set of AI dependencies.