Cloudflare ha afegit una cerca web API beta a AI Gateway, que ofereix als agents i a les aplicacions d'IA una manera de cercar a Internet en directe a través de la mateixa capa de passarel·la que ja s'utilitza per al trànsit del model. La funció és nova, de superfície reduïda i encara en versió beta, però apunta a un canvi més gran: la cerca s'està convertint en una eina d'IA facturable, no només una integració de l'aplicació.
L'empresa va anunciar la versió beta el 2 d'octubre de 2026. En el moment del llançament, Cloudflare inclou Ceramic.ai, Exa i Linkup com a proveïdors de cerca seleccionables. Els desenvolupadors poden enviar sol·licituds de cerca mitjançant AI Gateway, fer que aquestes sol·licituds apareguin als registres de la passarel·la i pagar-les mitjançant crèdits d'AI Gateway al preu API indicat per cada proveïdor. Cloudflare diu que no està afegint un marcatge addicional. Els equips també poden utilitzar les credencials del proveïdor de la teva pròpia clau quan siguin compatibles.
Aquesta combinació és important perquè s'uneix a tres preocupacions que sovint es gestionen per separat: l'encaminament de l'eina, l'observabilitat i la facturació. Per als desenvolupadors que creen agents augmentats per la recuperació, assistents d'investigació, robots de suport o fluxos de treball de vendes automatitzats, la pregunta ja no és només quin model va generar la resposta. També és a quin proveïdor de cerca es va trucar, amb les credencials del qual, a quin preu i si la despesa resultant es pot vincular a un client, equip, projecte o clau API.
Què ha canviat
Fins fa poc, moltes discussions sobre la passarel·la d'IA es van centrar en les trucades de models: OpenAIpunts finals compatibles, migració per error del proveïdor, comptabilitat de testimonis, latència, memòria cau i registres de sol·licituds. La beta API de la cerca web de Cloudflare afegeix un tipus de transacció diferent a aquest pla de control. Una trucada de cerca pot donar suport a una resposta de model, però no és en si mateixa una sol·licitud d'inferència de model. Té preus diferents, semàntica de proveïdor diferent i preguntes de govern diferents.
El llançament de Cloudflare fa que el proveïdor de cerca sigui una opció de passarel·la configurable en lloc d'una dependència de l'aplicació codificada. Els desenvolupadors poden triar entre els proveïdors de la llista, encaminar la trucada a través d'AI Gateway i veure-la juntament amb un altre trànsit d'IA. Si el client utilitza la facturació gestionada per Cloudflare, el càrrec s'aplica als crèdits d'AI Gateway. Si el client porta una clau de proveïdor, la passarel·la encara es pot situar al camí d'encaminament i registre.
Aquest és un límit de producte significatiu. La cerca ja no és un ajudant invisible amagat darrere d'un marc d'agent. Es converteix en un esdeveniment de primer nivell en els registres de la passarel·la. Per a una passarel·la multimodel API per a equips, aquesta és la diferència entre "l'agent era car" i "aquest flux de treball va gastar diners en fitxes de model, context en memòria cau i sis trucades de cerca en directe".
Per què els equips de passarel·la haurien de preocupar-se
El públic immediat són els desenvolupadors que ja utilitzen Cloudflare AI Gateway, especialment aquells que creen aplicacions que necessiten informació actualitzada. La cerca pot ajudar a les respostes a les dades en directe, però també introdueix una altra unitat de cost i una altra font de dependència del proveïdor. Si un agent d'assistència cerca documentació, un assistent de compliment verifica les pàgines de polítiques actuals o un flux de treball de vigilància del mercat escaneja el web repetidament, els càrrecs de cerca poden arribar a ser importants des del punt de vista operatiu fins i tot quan l'ús del testimoni sembla modest.
Aquest és el mateix patró que apareix ara a la infraestructura de l'agent. Les eines de shell allotjades, l'ús del navegador, els agents de revisió de codi i els serveis de recuperació s'estan convertint en operacions mesurades al voltant del model. Les fitxes encara importen, però ja no són tot el llibre major. Una passarel·la utilitzable ha d'explicar la despesa en tot el flux de treball, no només la finalització final.
Per a les empreses, això afecta la devolució i el marge. És possible que un distribuïdor o un equip de plataforma interna hagi de decidir si la despesa de cerca es transmet al preu de llista del proveïdor, es marca, s'agrupa en un pla o es bloqueja de manera predeterminada. És possible que un equip de finances vulgui saber si la factura d'un client ha augmentat a causa d'indicacions més grans, més fitxes de sortida, comportament de la memòria cau o volum de cerca web. És possible que els equips de producte desitgin informes d'ús que distingeixin l'enriquiment en segon pla de la generació visible per l'usuari.
Això crea una obertura pràctica per a una IA unificada API facturació més forta. El model de facturació ha de cobrir fitxes, fitxes emmagatzemades en memòria cau i trucades d'eines sense aplanar-les en una única línia vaga d'"ús de l'IA". En cas contrari, els clients no poden saber quina part d'un sistema d'agent genera els costos.
Les conseqüències del desenvolupador
Els desenvolupadors hauran de tractar la cerca web com a part del disseny API de l'aplicació, no només com una millora ràpida. El proveïdor de cerca ha de ser visible a la configuració. Les credencials s'han d'abastar. Els registres haurien de conservar prou informació per depurar el comportament del proveïdor i la despesa del client sense retenir dades sensibles innecessàries. La gestió d'errors hauria de distingir una fallada del model d'una fallada del proveïdor de cerca, perquè l'experiència de l'usuari i l'estratègia de reintent poden ser diferents.
També hi ha una pregunta d'encaminament. Ceramic.ai, Exa i Linkup no són intercanviables en tots els casos d'ús. La qualitat de la cerca, la cobertura, la latència, el format del resultat i el preu poden afectar el comportament del model aigües avall. Una passarel·la que pot encaminar entre proveïdors ofereix flexibilitat als desenvolupadors, però també requereix una política: quin proveïdor està aprovat per a quin inquilí, quines regions o classes de dades es permeten i si es requereixen credencials BYOK per a alguns clients.
Per a productes Model Gate i similars, la connexió pràctica és directa. Si els clients estan creant serveis d'agent a sobre d'una passarel·la, finalment demanaran que l'ús de la cerca aparegui al costat de l'ús del model a la mateixa superfície d'anàlisi. És possible que les API de partner també hagin d'exposar els registres de trucades de cerca perquè les plataformes posteriors puguin facturar als seus propis clients amb precisió. Tractar la cerca com una eina facturable de primera classe encaixaria naturalment al costat de la gestió de APIclaus, els controls d'equip i l'anàlisi d'ús.
Això no vol dir que totes les passarel·les hagin de copiar la llista exacta de proveïdors de Cloudflare. El punt més important és estructural: una vegada que la cerca en directe està disponible a través d'una passarel·la, el mesurament d'eines passa a formar part del contracte de la passarel·la. Una IA d'equip API control de la despesa que ignora les trucades d'eines subestimarà el cost real de l'agent.
Què segueix sent incert
L'estat beta deixa diverses preguntes obertes. Cloudflare ha nomenat els proveïdors de cerca inicials i ha descrit l'enfocament de facturació, però els equips de producció encara hauran d'avaluar el rendiment específic del proveïdor, la qualitat dels resultats, els compromisos de gestió de dades i els límits operatius. La documentació pública confirma la versió beta i la ruta bàsica de preus, però no determina si un proveïdor és millor per a totes les càrregues de treball o com evolucionarà la funció abans de la disponibilitat general.
Tampoc està clar amb quina rapidesa els desenvolupadors estandarditzaran la cerca mediada per passarel·la en lloc de les integracions directes dels proveïdors. Els equips amb piles de recuperació existents poden mantenir la cerca dins de la seva pròpia infraestructura. Altres poden preferir l'encaminament de passarel·la perquè redueix el treball d'integració i centralitza els registres. La decisió probablement dependrà de les necessitats de govern tant com de la rellevància de la cerca.
Tot i així, la direcció és prou clara. Les passarel·les d'IA absorbeixen més temps d'execució de l'agent al voltant del model. La cerca web API beta de Cloudflare no és només una funció de cerca; és un altre senyal que ara el pla de control de les aplicacions d'IA ha de mesurar, encaminar i explicar les eines amb la mateixa cura que maneja els models.