Cloudflare Web Search API: Anbieter, Preise und der 28-fache Unterschied

Was die Cloudflare Web Search API eigentlich ist

Der Pitch im Launch-Beitrag von Michelle Chen, Sam Else und Gabriel Massadas beginnt mit einem netten Eingeständnis. Braucht ein Agent eine aktuelle Seite, errät er meist die URL und ruft sie per curl ab, weshalb man in Agenten-Logs so viele 404er sieht. Websuche gibt dem Agenten einen echten Ausgangspunkt: Anfrage senden, Ergebnisliste erhalten, ins Modell einspeisen.

Technisch ist es eine Routing-Schicht, keine Suchmaschine. Die About-Seite von Cloudflare nennt vier Schritte für jede Anfrage:

1. Die Anfrage über das von dir benannte AI Gateway leiten.
2. Die Anfrage an den gewählten Anbieter weiterleiten, oder an Ceramic.ai, wenn du keinen gewählt hast.
3. Die Antwort in ein Format normalisieren: URL, Titel und optional Beschreibung, Bild, Favicon und Datum der letzten Änderung.
4. Die Anfrage protokollieren und deinem Konto in Rechnung stellen.

Das ist heute das ganze Produkt, und das meine ich als Kompliment. Wenn du Modellaufrufe schon über AI Gateway laufen lässt, erscheint die Suche jetzt in denselben Logs, im selben Budget und unter denselben Zugriffsregeln. Cloudflare sagt außerdem, dass Server-Tools kommen, sodass Websuche später in die Control Plane eingebaut ist, statt ein Werkzeug zu sein, das du selbst anbindest.

Der Launch fiel in die Birthday Week und hat offensichtlich einen Nerv getroffen. Der Hacker-News-Thread kam auf 590 Punkte und 284 Kommentare, mehr als der Launch des Kitesurf-Browsers. Cloudflares eigene Ankündigung auf X bekam eine Antwort, die zusammenfasst, warum das Thema die Leute interessiert:

"search in the same gateway as the model calls is the nice part. wiring exa into my agent tonight"

Avery Coree, X

Wie eine Anfrage abläuft

Bevor es ums Geld geht, lohnt ein Blick auf die beweglichen Teile, denn jede interessante Entscheidung steckt in einem davon.

Du kannst sie auf zwei Arten aufrufen, beide auf der How-to-Seite dokumentiert:

• REST: POST https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/websearch/, authentifiziert mit einem Cloudflare-API-Token, das sowohl die Berechtigung Workers AI Read als auch AI Gateway Read hat.
• Workers-Binding: env.AI.websearch({ gatewayId, query, provider, limit }), das eine Standard-Response zurückgibt, auf der du .json() aufrufst.

Die Anfrage hat nur sehr wenige Stellschrauben, was viel über das Design verrät:

Es gibt keinen Datumsfilter, keine Domain-Allowlist, keinen Länderparameter und keine Option, die ganze Seite abzurufen. Jeder Anbieter läuft in einem festen Modus: Exa nutzt seinen Suchtyp auto mit Highlights als Beschreibung, Linkup nutzt die Tiefe fast mit Rohergebnissen, laut Anbieterseite. Wenn du die tieferen Modi von Exa oder Linkup brauchst, rufst du sie direkt auf.

Die Antwort ist bewusst schlank: ein items-Array und ein metadata-Block mit deiner Anfrage, einer Request-ID und latencyMs. Diese Schlankheit ist der Punkt. Sie passt ohne einen Parser pro Anbieter direkt in das Kontextfenster eines Modells, und Cloudflares Docs enthalten ein vollständiges Beispiel, wie man sie als web_search-Tool für ein Modell wie Gemma 4 auf Workers AI einbindet.

Warum der Anbieter-Parameter die eigentliche Preisentscheidung ist

Hier ist die Tabelle, auf die es ankommt. Alle Zahlen stammen von Cloudflares Anbieterseite, geprüft am 8. Oktober 2026:

Exa kostet das 28-Fache von Ceramic bei gleicher Anfrageform, und der Wechsel dazwischen ist ein einziger String. Das ist hervorragend zum Experimentieren und gefährlich fürs Budget, denn in deinem Code ändert sich nichts, wenn ein Teammitglied in einer Konfigurationsdatei ceramic auf exa umstellt. Ein HN-Kommentator, der die Preisliste postete, stellte die richtige Frage:

"Does anyone have insights on the quality differences? Web search API pricing for AI agent usecases has always felt so expensive for what it is, but I have no grounding on the economics of running a web index."

8bite, Hacker News

Cloudflares Launch-Beitrag enthält einen Log-Screenshot, der die Kosten pro Suche sehr konkret macht: ein einzelner exa/search-Aufruf, abgerechnet mit 0,007 $, genau 7,00 $ pro 1.000.

Die Aussage „kein Aufschlag“, genau gelesen

Cloudflare sagt, Suchen würden „at each provider's list API price, with no additional markup“ abgerechnet. Das stimmt pro Suche. Aber AI-Gateway-Guthaben stammt aus Unified Billing, und diese Seite nennt, dass auf alle gekauften Guthaben eine Gebühr von 5 % anfällt: Eine Aufladung von 100 $ ist eine Abbuchung von 105 $. Zahlst du also mit Guthaben, liegt dein effektiver Preis etwa 5 % über Liste. Wenn du deinen eigenen Schlüssel mitbringst, rechnet der Anbieter direkt mit dir ab, und die Guthabengebühr entfällt für diese Suchen.

So sieht das bei realistischen Volumen aus, bei einer Suche pro Anfrage:

Die 5 % sind ein Rundungsfehler neben der Anbieterwahl. Bei einer Million Suchen im Monat ist die Wahl von Exa statt Ceramic zum Listenpreis eine Entscheidung über 6.750 $; die Guthabengebühr obendrauf beträgt höchstens 350 $. Agenten suchen außerdem selten nur einmal pro Aufgabe. Eine Recherche-Schleife mit fünf Suchen pro Nutzerfrage macht aus 200.000 Fragen eine Million Suchen, und so landet ein „günstiges“ Feature in der Finanzprüfung. Wenn du eigene Zahlen einsetzen willst, übernimmt dieser Rechner die Multiplikation:

Was Cloudflare vereinheitlicht hat und was nicht

Das ist der Blickwinkel, den die meisten Berichte meiner Meinung nach verpassen. Cloudflare hat die drei Anbieter auf API-Ebene identisch aussehen lassen. Sie sind nicht identisch in den Punkten, die für ein Produktteam zählen.

Ein X-Beitrag bringt es besser auf den Punkt, als ich es könnte:

"The catch is that a unified endpoint also makes search providers look interchangeable when result quality, coverage, ranking, and failure modes probably won’t be."

Hero.S, X

Drei Lücken solltest du prüfen, bevor du live gehst.

Datenspeicherung sagt zwei verschiedene Dinge

Der Changelog-Eintrag sagt „all three support Zero Data Retention for requests made through Cloudflare.“ Die Anbieterseite, am selben Tag aktualisiert, führt Exa mit „Zero Data Retention: No“. Beide Seiten sagten das noch, als ich am 8. Oktober nachsah. Ein HN-Leser bemerkte es innerhalb von Stunden, und jemand von Exa antwortete:

"Thanks for raising this! We're looking into this discrepancy (I work at Exa)."

alexey-salmin, Hacker News

Bis beides übereinstimmt, würde ich davon ausgehen, dass die Anbietertabelle stimmt. Wenn deine Anfragen Kundennamen, Bestellnummern oder irgendetwas aus einem Ticket enthalten, sind Ceramic oder Linkup damit die sicheren Wahlen. Beachte außerdem, dass die ZDR-Einstellung von Unified Billing das Logging von AI Gateway nicht steuert; das ist ein separater Schalter.

Was du speichern darfst, regeln die Bedingungen des jeweiligen Anbieters

Cloudflare hat das JSON vereinheitlicht. Die Lizenz nicht. Simon Willison stellte die Frage, die jedes Produkt mit einem „Chat teilen“-Button stellen sollte:

"My number one question about search APIs is always if they allow you to store and resyndicate results you get from them."

simonw, Hacker News

Er zitierte dann die Nutzungsbedingungen von Ceramic, die es untersagen, Ausgaben über das hinaus aufzubewahren, zu cachen oder zu speichern, was „reasonably necessary to display such Output to your authorized end users in the ordinary and real-time course of use“ ist. Wenn dein Agent Suchergebnisse in ein gespeichertes Transkript, eine Wissensdatenbank oder einen Cache schreibt, lies die Bedingungen des gewählten Anbieters. Exa und Linkup verlinken ihre eigenen Bedingungen in derselben Anbietertabelle.

Ergebnisqualität ist kein Parameter

Der günstigste Anbieter ist der Standard, und die Docs beschreiben Ceramic als für „low-latency, low-cost search“ gebaut. Frühe Tester fanden seinen Index ungleichmäßig:

"Tried one query on ceramic.ai (the default provider for cloudflare web search api): "qwen-3.8 flash next and rtx 5090 best inference setup" ... 0 results ... same query on google and ddg both yield proper results."

freakynit, Hacker News

Eine Anekdote ist kein Benchmark, und Exas Head of Index merkte im selben Thread fairerweise an, dass die Suchqualität je nach Anfragetyp schwankt. Aber es erinnert daran, dass eine leere Ergebnismenge ein normales Ergebnis ist, mit dem dein Agent umgehen muss, kein Randfall. Mehr dazu, warum das wichtig ist, weiter unten.

Web Search API im Vergleich zu anderen Wegen, einem Agenten Suche zu geben

Cloudflare hat jetzt tatsächlich zwei Dinge, die „Web Search“ heißen, was einige Leser verwirrt hat. Die ältere Web-Search-Seite von AI Gateway, im Juni aktualisiert, behandelt das Durchreichen des jeweiligen Suchwerkzeugs der Modellanbieter. Die neue API ist ein separates Produkt.

Wenn du die API von Anthropic oder die API von OpenAI nutzt und mit deren eingebauter Suche zufrieden bist, sind die nativen Tools weniger Aufwand. Die Web Search API verdient ihren Platz, wenn du offene Modelle betreibst, etwa Kimi K3 oder die Modelle hinter DeepSeek Harness, die keinen eigenen Suchpartner haben. Ein HN-Kommentator vermutete genau das: Die großen Coding-Agenten kommen mit Suchpartnern, offene Modelle brauchen die Suche von irgendwoher.

Viele Entwickler fragten „Warum nicht die Anbieter direkt aufrufen?“ Die ehrliche Antwort aus dem Thread lautet Beschaffung und Budgets, nicht Technik. Ein Kommentator beschrieb, wie er einem Agenten ein einziges Cloudflare-Token mit Ausgabenlimits gab, statt für jeden Dienst einen Proxy zu bauen:

"Instead I put my API keys to cloudflare, set limits, and gave the agent the CloudFlare token, and in minutes it could contact tens of services."

bayesianbot, Hacker News

Das passt zu dem, was Cloudflare dokumentiert: Ausgabenlimits pro Gateway, eingegrenzt nach Modell, Anbieter oder benutzerdefinierten Metadaten. Wenn dein Team ohnehin Cloudflare bezahlt, ist das Hinzufügen von Suche ein Budgetposten, keine neue Anbieterprüfung. Wenn nicht, ist eine direkte Integration mit Exa oder einem Scraper wie Firecrawl vielleicht genauso schnell. Auch die Landschaft verschiebt sich: Googles Custom Search JSON API ist für Neukunden geschlossen, und Bestandskunden haben bis zum 1. Januar 2027, um umzusteigen.

Wo das für einen Support-Agenten passt und wo nicht

Meine Voreingenommenheit vorab. Ich arbeite seit zwei Jahren in SEO, und das Erste, was man dort lernt, ist, dass die Suchintention alles entscheidet. Ein Kunde, der fragt „Kann ich das nach 30 Tagen noch zurückgeben?“, fragt nicht das Internet. Er fragt dich. Die richtige Quelle ist deine Rückgaberichtlinie, nicht die Top 10 für „30 Tage Rückgaberecht“.

Das ist wichtig wegen eines Fehlers, den ich aus nächster Nähe gesehen habe. Ich habe zahlende eesel-Kunden erlebt, deren Bot echten Kunden mit erfundenen Aussagen antwortete, wenn die Suche in der Wissensdatenbank leer blieb; eine Antwort zog „Oxygen“ aus dem Periodensystem. Die Lösung war nicht mehr Suche. Es war ein harter Fallback: Wenn deine eigenen Quellen nichts haben, an einen Menschen übergeben, statt das Modell die Lücke füllen zu lassen, womit es kann. Eine allgemeine Websuche-API macht diese Lücke größer, nicht kleiner, denn nun hat das Modell das ganze Internet, aus dem es selbstsicher falsch liegen kann. Die Muster sind in eesels Leitfaden zu KI-Halluzinationen im Support beschrieben.

Für den Support würde ich die Quellen also so ordnen:

1. Dein Help Center, Makros und vergangene Tickets. Das sollte Retrieval-Augmented Generation für den Support bedeuten.
2. Deine eigene Website und Produktdokumentation, auf deine Domain beschränkt.
3. Das offene Web zuletzt, für Fragen, die wirklich die Außenwelt betreffen: der Ausfall eines Versanddienstleisters, eine öffentliche Vorschrift, das Changelog der Integration eines Drittanbieters.

Die Cloudflare Web Search API ist ein vernünftiges Werkzeug für diesen dritten Bereich. Sie ersetzt die ersten beiden nicht, und Cloudflare bewirbt sie auch nicht so.

Wie eesel neben einer Such-API passt

Websuche ist Infrastruktur. eesel ist der Mitarbeiter. Cloudflare gibt deinem Agenten eine Möglichkeit, Dinge nachzuschlagen; eesel gibt dir einen einsatzbereiten Teammate, der schon weiß, wo deine Antworten liegen. Der AI-Helpdesk-Teammate steigt in deine bestehende Warteschlange in Tools wie Zendesk ein, lernt aus deinem Help Center und vergangenen Tickets, entwirft oder sendet Antworten und eskaliert, wenn er keine fundierte Antwort hat. Zum aktuellen Team gehört auch ein AI-Blog-Writer für Content-Teams.

Wenn du zu den Teams gehörst, die Cloudflare-Changelogs zum Spaß lesen, wird dir die eesel CLI wahrscheinlich gefallen. Sie führt denselben Teammate aus einem Terminal aus, und alles, was du dort einrichtest, erscheint im Dashboard. Die Befehle passen gut zur Idee „zuerst deine Quellen“:

• npx @eesel/cli init chat-bubble --site https://your-site.com erstellt einen Agenten, der anfängt, deine eigene Website zu lesen, ohne Konto für einen 7-tägigen Test-Workspace.
• eesel integrations connect website --url ... oder eesel integrations connect <platform> fügt dein Helpdesk oder deine Docs als Wissen hinzu, und eesel files upload ./refund-policy.pdf fügt eine einzelne Richtlinie hinzu.
• eesel chat "what's our refund policy?" testet die Antwort, bevor ein Kunde sie je sieht.
• eesel approvals listet Aktionen auf, die auf einen Menschen warten, sodass ein Schreibvorgang, den der Agent ausführen will, auf Freigabe wartet.

Jeder Befehl gibt JSON aus, und jeder Fehler kommt mit einem hint zurück, sodass ein Coding-Agent wie Claude Code oder Codex die ganze Einrichtung ausführen und seine eigenen Ergebnisse lesen kann. eesel mcp token macht den Workspace außerdem zu einem MCP-Server, womit ich ihn an einen Agenten anbinden würde, der Cloudflare bereits für die Suche nutzt. Es ist dasselbe Muster, das ich in CLI für den Kundensupport behandelt habe: ein Terminal, Skripte und Agenten steuern denselben Teammate.

Wo eesel nicht die richtige Wahl ist: Wenn du einen allgemeinen Recherche-Agenten baust, der von öffentlichen Webdaten lebt, willst du eine Such-API wie die von Cloudflare, keinen Helpdesk-Teammate.

Mein Fazit zur Cloudflare Web Search API

Es ist ein sauberes, kleines, ehrliches Produkt. Drei Dinge würde ich tun, bevor ich mich darauf verlasse:

• Den provider explizit festlegen, auch wenn du Ceramic willst. Ein Standard, den du nicht aufgeschrieben hast, ist ein Standard, den jemand ändert, ohne einen 28-fachen Preisunterschied zu bemerken.
• Die ZDR-Spalte bei Exa als ungeklärt behandeln, bis Changelog und Anbieterseite übereinstimmen, und die Speicherbedingungen des Anbieters lesen, bei dem du bleibst.
• Null Ergebnisse gezielt behandeln. „Ich weiß es nicht“ zurückgeben oder übergeben, statt das Modell improvisieren zu lassen. Das ist die einzige Gewohnheit, die AI Grounding davor bewahrt, zu KI-Halluzination zu werden.

Wenn du ohnehin auf Cloudflare baust, ist es der einfachste Weg, den ich kenne, einem offenen Modell Live-Suche mit einer Rechnung und einem Log zu geben. Wenn du Suche für einen kundenorientierten Agenten bewertest, starte mit deinem eigenen Wissen und nimm das Web als letzten Ausweg dazu. Mehr zum Cloudflare-Agenten-Stack findest du in meinen Notizen zu Clef-Entscheidungsmodellen und den Kitesurf-Alternativen, oder stöbere im breiteren Feld der KI-Suchmaschinen.

eesel für fundierte Support-Antworten testen

Wenn du dir eine Websuche-API ansiehst, weil dein Support-Bot immer wieder Antworten aus der Luft greift, liegt die Lösung meist näher. Der AI-Helpdesk-Teammate von eesel lernt aus deinem Help Center, deinen Makros und vergangenen Tickets und eskaliert an dein Team, wenn er nichts Fundiertes zu sagen hat. Du kannst ihn an deiner eigenen Wissensdatenbank testen, bevor er ein Live-Ticket anfasst, und Tarife auf der Preisseite ansehen. Teste eesel kostenlos.