Il 2 ottobre 2026 Cloudflare ha messo in beta la Web Search API: un modo unico per far cercare il web agli agenti (e alle app) senza inventare URL o restare bloccati al training cutoff del modello. Non è un motore di ricerca nuovo: è un adapter. Tre provider dietro, un contratto REST o un binding Workers, e tutto che passa da AI Gateway.
Aggiornamento del 21 ottobre 2026: a quasi tre settimane dal lancio la API è ancora in open beta e la pagina dei provider non è cambiata: stessi tre provider, stessi prezzi, stessa retention. La novità è dal lato agenti: dal 12 ottobre l'Agents SDK di Cloudflare (dalla v0.27.0) ha un tool web_search costruito su questa API, con adapter per AI SDK e TanStack AI.
Cosa cambia davvero
Prima, se volevi grounding live, sceglievi un vendor (Exa, Linkup, un altro), gestivi chiave, logging e billing a parte, e lo attaccavi al tuo tool schema. Ora puoi chiamare un endpoint Cloudflare — o env.AI.websearch() da un Worker — e scegliere il provider nel payload.
I tre provider al lancio sono Ceramic.ai (default), Exa e Linkup. Ceramic usa un indice proprio, che la documentazione Cloudflare descrive come oltre 40 miliardi di pagine, pensato per agenti e con prezzo aggressivo. Exa combina keyword ed embeddings e restituisce come descrizione gli estratti più pertinenti alla query. Linkup restituisce risultati con snippet, in modalità fast, adatta a tool call che non vogliono una risposta generata dal provider.
Il pezzo importante per chi opera in produzione non è solo “posso cercare”. È che le ricerche finiscono nei log di AI Gateway come le altre chiamate modello: stessa osservabilità, stessi crediti (o BYOK sul gateway), senza markup sopra il listino del provider.
Cosa conviene guardare prima di usarla
Prezzo e retention non sono uguali. Sui docs provider, Ceramic è a 0,25$ per 1.000 richieste con Zero Data Retention. Linkup è a 5$ per 1.000 con ZDR. Exa è a 7$ per 1.000 e sui docs risulta senza ZDR. Se i tuoi agenti mandano query con dati sensibili, la scelta del provider non è gusto: è policy.
Il parametro limit va da 1 a 10 risultati (10 di default) e la query si ferma a 1.024 caratteri, secondo i limiti della guida ufficiale. Non è un crawler full-page: è search per grounding. Se ti serve il contenuto completo di una pagina resta un altro pezzo di pipeline. Nell'Agents SDK quel pezzo è il tool web_fetch, e quando li dai entrambi all'agente il modello viene istruito a leggere con web_fetch le pagine trovate da web_search.
Serve un AI Gateway (ogni account ne ha uno di nome default) e crediti caricati sul gateway, oppure una chiave del provider salvata sul gateway. Il token Cloudflare per la REST API deve avere due permessi: Workers AI Read e AI Gateway Read. Con la chiave sul gateway puoi anche passare un alias: se non è configurato la richiesta fallisce con un 400 invece di scalare sui crediti. Log, cache e spend limit del gateway li spiego nel pezzo su Cloudflare AI Gateway.
Quando ha senso (e quando no)
Ha senso se già sei su Workers / AI Gateway e vuoi un tool di search uniforme nei log, con la possibilità di cambiare provider senza riscrivere il client. Ha senso anche se vuoi BYOK: la chiave resta sul gateway, non nel payload.
Ha meno senso se il tuo stack è già agganciato a un solo vendor con contratti, rate limit e feature avanzate che l’adapter Cloudflare non espone ancora. In beta, trattalo come controllo e unificazione — non come sostituto totale del prodotto nativo del provider.
Il collegamento con il pezzo sugli agenti
Un agente che “cerca” senza un tool chiaro produce loop sporchi. Qui il tool è esplicito: query, provider, limit, gateway. Se usi l'Agents SDK non devi neanche scriverlo: il tool web_search riceve dal modello query e numero massimo di risultati e restituisce una lista numerata di titoli, URL e descrizioni accorciate. Per i job senza modello, come un cron, ci sono createAIWebSearch() e createHTTPWebSearch(). Come per qualunque tool, conta descriverlo bene: cosa restituisce, quando usarlo, quando no. Ne parlo in dalla prompt alla graph engineering e nel pezzo sul tool engineering. La Web Search API riduce il pezzo infrastrutturale; non sostituisce il giudizio su quando un agente non serve e basterebbero un cron e uno script.
In sintesi: se i tuoi agenti devono groundarsi sul web e vivi già nell’ecosistema Cloudflare, questa beta è il pezzo che mancava tra binding AI e osservabilità. Scegli il provider per retention e costo, non per il comunicato stampa. Se automatizzi anche il deploy con agenti, guarda come cambia la CLI con cf al posto di Wrangler.
Domande frequenti
01Quanto costa la Web Search API di Cloudflare?
Si paga il listino del provider senza ricarico: 0,25 $ ogni 1.000 richieste con Ceramic.ai, 5 $ con Linkup e 7 $ con Exa (pagina provider controllata il 21 ottobre 2026). Con la tua chiave salvata sul gateway ti fattura direttamente il provider.
02Quali provider della Web Search API non conservano le query?
Secondo la documentazione Cloudflare, Ceramic.ai e Linkup hanno Zero Data Retention, Exa no. Se le query degli agenti contengono dati sensibili, scegli il provider su questo prima che sul prezzo.
03Quanti risultati restituisce una ricerca?
Da 1 a 10, con 10 come valore di default, e la query può essere lunga al massimo 1.024 caratteri. Per leggere le pagine intere serve un passaggio separato, per esempio il tool web_fetch dell'Agents SDK.
04Si può usare con l'Agents SDK di Cloudflare?
Sì. Dal 12 ottobre 2026 l'Agents SDK, dalla versione 0.27.0, include un tool web_search basato su questa API, con adapter per AI SDK e TanStack AI.
