Cloudflare har tilføjet en websøgning API beta til AI Gateway, hvilket giver agenter og AI-applikationer en måde at søge på live-internettet gennem det samme gateway-lag, som allerede er brugt til modeltrafik. Funktionen er ny, snæver i overfladeareal og stadig i beta, men den peger på et større skift: søgning er ved at blive et fakturerbart AI-værktøj, ikke kun en integration på applikationssiden.

Virksomheden annoncerede betaen den 2. oktober 2026. Ved lanceringen angiver Cloudflare Ceramic.ai, Exa og Linkup som valgbare søgeudbydere. Udviklere kan sende søgeanmodninger gennem AI Gateway, få disse anmodninger vist i gateway-logfiler og betale for dem gennem AI Gateway-kreditter til hver udbyders angivne pris API. Cloudflare siger, at det ikke tilføjer en ekstra markup. Teams kan også bruge loginoplysninger for udbyder medbring-din-egen-nøgle, hvor det understøttes.

Denne kombination er vigtig, fordi den forbinder tre problemer, der ofte håndteres separat: værktøjsruting, observerbarhed og fakturering. For udviklere, der bygger genfindingsforstærkede agenter, forskningsassistenter, supportbots eller automatiserede salgsarbejdsgange, er spørgsmålet ikke længere kun, hvilken model der genererede svaret. Det er også, hvilken søgeudbyder der blev kaldt, under hvis legitimationsoplysninger, til hvilken pris, og om det resulterende forbrug kan knyttes tilbage til en kunde, et team, et projekt eller API-nøgle.

Hvad ændrede sig

Indtil for nylig var mange AI-gateway-diskussioner centreret om modelkald: OpenAI-kompatible slutpunkter, provider-failover, token-kontering, latency, caching og anmodningslogfiler. Cloudflares websøgning API beta tilføjer en anden form for transaktion til det pågældende kontrolplan. Et søgeopkald understøtter muligvis et modelsvar, men det er ikke i sig selv en modelslutningsanmodning. Det har forskellige priser, forskellig udbydersemantik og forskellige styringsspørgsmål.

Cloudflares lancering gør søgeudbyderen til et konfigurerbart gatewayvalg snarere end en hårdkodet applikationsafhængighed. Udviklere kan vælge blandt de listede udbydere, dirigere opkaldet gennem AI Gateway og se det sammen med anden AI-trafik. Hvis kunden bruger Cloudflare-administreret fakturering, løber opkrævningen mod AI Gateway-kreditter. Hvis kunden medbringer en udbydernøgle, kan gatewayen stadig sidde i stien til routing og logning.

Det er en meningsfuld produktgrænse. Søgning er ikke længere en usynlig hjælper skjult bag en agentramme. Det bliver en førsteklasses begivenhed i gateway-rekorder. For en multi-model API gateway for teams er det forskellen mellem "agenten var dyr" og "denne arbejdsgang brugte penge på modeltokens, cachelagret kontekst og seks live søgeopkald."

Hvorfor gateway-teams bør bekymre sig

Den umiddelbare målgruppe er udviklere, der allerede bruger Cloudflare AI Gateway, især de, der bygger applikationer, der har brug for frisk information. Søgning kan hjælpe med at jorde svar i live data, men det introducerer også en anden omkostningsenhed og en anden kilde til udbyderafhængighed. Hvis en supportmedarbejder søger i dokumentation, en overholdelsesassistent tjekker aktuelle politiksider, eller en markedsovervågningsworkflow scanner internettet gentagne gange, kan søgegebyrer blive operationelt vigtige, selv når tokenbrug ser beskedent ud.

Dette er det samme mønster, der nu vises på tværs af agentinfrastruktur. Hostede skalværktøjer, browserbrug, kodegennemgangsagenter og genfindingstjenester bliver alle til målte operationer omkring modellen. Tokens betyder stadig noget, men de er ikke længere hele hovedbogen. En brugbar gateway skal forklare forbrug på tværs af hele workflowet, ikke kun den endelige afslutning.

For virksomheder påvirker det tilbageførsel og margen. En forhandler eller internt platformsteam skal muligvis beslutte, om søgeudgifter sendes til udbyderens listepris, opmærkes, samles i en plan eller blokeres som standard. Et økonomiteam vil måske vide, om en kundes faktura steg på grund af større prompter, flere outputtokens, cacheadfærd eller websøgningsvolumen. Produktteams ønsker måske brugsrapporter, der adskiller baggrundsberigelse fra brugersynlig generation.

Det skaber en praktisk åbning for stærkere unified AI API fakturering. Faktureringsmodellen skal dække tokens, cachede tokens og værktøjsopkald uden at udjævne dem til en enkelt vag "AI-brug"-linje. Ellers kan kunder ikke se, hvilken del af et agentsystem, der driver omkostningerne.

Udviklerkonsekvenserne

Udviklere bliver nødt til at behandle websøgning som en del af applikationens API-design, ikke kun som en hurtig forbedring. Søgeudbyderen skal være synlig i konfigurationen. Legitimationsoplysninger bør være omfattet. Logfiler bør bevare nok information til at fejlsøge udbyderens adfærd og kundeforbrug uden at gemme unødvendige følsomme data. Fejlhåndtering bør skelne en modelfejl fra en søgeudbyderfejl, fordi brugeroplevelsen og genforsøgsstrategien kan være anderledes.

Der er også et routing-spørgsmål. Ceramic.ai, Exa og Linkup er ikke udskiftelige i alle tilfælde. Søgekvalitet, dækning, latens, resultatformat og prissætning kan alle påvirke downstream-modellens adfærd. En gateway, der kan rute mellem udbydere, giver udviklere fleksibilitet, men den kræver også politik: Hvilken udbyder er godkendt til hvilken lejer, hvilke regioner eller dataklasser er tilladt, og om BYOK-legitimationsoplysninger er påkrævet for nogle kunder.

For Model Gate og lignende produkter er den praktiske forbindelse direkte. Hvis kunder bygger agenttjenester oven på en gateway, vil de i sidste ende bede om, at søgebrug vises ved siden af ​​modelbrug i den samme analyseflade. Partner-API'er skal muligvis også afsløre registreringer af søgeopkald, så downstream-platforme kan fakturere deres egne kunder nøjagtigt. At behandle søgning som et førsteklasses fakturerbart værktøj ville passe naturligt ved siden af API-nøglestyring, teamkontrol og brugsanalyse.

Det betyder ikke, at alle gateways skal kopiere Cloudflares nøjagtige udbyderliste. Det vigtigere punkt er strukturelt: Når en livesøgning er tilgængelig gennem en gateway, bliver værktøjsmåling en del af gatewaykontrakten. Et team AI API spend control, der ignorerer værktøjsopkald, vil undervurdere reelle agentomkostninger.

Hvad er fortsat usikkert

Betastatus efterlader flere åbne spørgsmål. Cloudflare har navngivet de indledende søgeudbydere og beskrevet faktureringstilgangen, men produktionshold skal stadig evaluere udbyderspecifik ydeevne, resultatkvalitet, datahåndteringsforpligtelser og operationelle grænser. Offentlig dokumentation bekræfter betaen og den grundlæggende prissti, men den afgør ikke, om én udbyder er bedre til alle arbejdsbelastninger, eller hvordan funktionen vil udvikle sig før den generelle tilgængelighed.

Det er også uklart, hvor hurtigt udviklere vil standardisere omkring gateway-medieret søgning frem for direkte udbyderintegrationer. Hold med eksisterende genfindingsstabler kan holde søgning i deres egen infrastruktur. Andre foretrækker måske gateway-routing, fordi det reducerer integrationsarbejdet og centraliserer logfiler. Beslutningen vil sandsynligvis afhænge af styringsbehov lige så meget som søgerelevans.

Alligevel er retningen klar nok. AI-gateways absorberer mere af agentens køretid omkring modellen. Cloudflares websøgning API beta er ikke kun en søgefunktion; det er endnu et tegn på, at kontrolplanet til AI-applikationer nu skal måle, rute og forklare værktøjer lige så omhyggeligt, som det håndterer modeller.