Was ist eine Web-Search-API für KI-Agenten?

Was passiert während eines Aufrufs?

Fünf Dinge, der Reihe nach, wobei Anbieter einige davon verbergen:

1. Anfrageverarbeitung. Der Dienst bereinigt die Suchanfrage und wendet Ihre Filter an: Land, Sprache, Zeitraum, einbezogene oder ausgeschlossene Domains.
2. Suche. Er führt die Suchanfrage gegen einen Webindex aus, entweder seinen eigenen oder eine Live-Suchmaschine, und erhält eine geordnete Liste von URLs.
3. Lesen. Für die obersten Ergebnisse ruft er jede Seite ab und prüft, ob die Site es erlaubt.
4. Bereinigung. Er entfernt Navigation, Anzeigen und Skripte und behält den Hauptinhalt, meist als Markdown.
5. Verpackung. Er gibt alles als JSON zurück, bereit zum Einfügen in einen Prompt.

Mit LLMWebSearch umfasst Schritt 3 standardmäßig die ersten 3 Ergebnisse und bis zu 10 mit read.

Wie unterscheidet sie sich von einer SERP-API?

Eine SERP-API gibt die Seite mit den Suchergebnissen zurück; eine Web-Search-API für Agenten gibt die Quellen dahinter zurück. SERP-APIs spiegeln, was ein Mensch auf einer Suchmaschine sieht: Anzeigen, Karten, „People Also Ask“-Boxen, Shopping-Karten und zehn blaue Links. Das passt zu SEO-Tools und Rank-Tracking.

Ein Agent braucht weniger Layout und mehr Text. Er will eine saubere Liste von Quellen und die Wörter auf diesen Seiten. Mit einer SERP-API muss der Agent einen zweiten Dienst aufrufen, um jeden Link zu lesen. Eine Web-Search-API für Agenten erledigt beides in einem Aufruf.

Wie unterscheidet sie sich von einer Web-Reader-API?

Ein Reader startet von einer URL; eine Search-API startet von einer Frage. Ein Reader, oder Fetch-Tool, nimmt einen Link, den Sie bereits haben, und gibt dessen Inhalt zurück. Er kann Ihnen nicht sagen, welche Seiten zu lesen sind.

Agenten brauchen oft beides. Sie suchen, um Kandidaten zu finden, und lesen dann die besten. Eine Search-API, die auch liest, spart diesen zweiten Schritt für die obersten Ergebnisse. Wenn der Agent bereits URLs hat, zum Beispiel aus einer Nutzernachricht, genügt ein Read-Aufruf. LLMWebSearch bietet ihn als extract-Endpoint.

Wie unterscheidet sie sich vom integrierten Suchtool eines Modells?

Ein integriertes Tool sucht auf der Seite des Modellanbieters und gibt meist eine Antwort mit Zitaten zurück, nicht die Seiten. OpenAI, Anthropic, Google und Microsoft verkaufen alle eines. Stand 22. Oktober 2026 verlangen OpenAI und Anthropic 10 $ pro 1.000 Suchen plus den Suchinhalt als Tokens. Grounding mit Gemini 3 kostet 14 $ pro 1.000 nach 5.000 kostenlosen Suchen pro Monat im bezahlten Tarif. Grounding mit Bing kostet 14 $ pro 1.000.

Microsoft gibt an, dass Ergebnisse von Grounding mit Bing „nicht direkt zur Verwendung in anderen Anwendungen zugänglich“ sind. Eine eigenständige API gibt Rohquellen zurück, die Sie speichern, filtern und anzeigen können. Sie funktioniert außerdem mit jedem Modell. Der Vergleich der integrierten Tools enthält die Details.

Woher kommen die Ergebnisse?

Entweder aus dem eigenen Index des Anbieters oder aus einer Live-Suchmaschine, die zum Zeitpunkt des Aufrufs abgefragt wird. Brave sagt, jedes Ergebnis stamme aus seinem eigenen unabhängigen Index. Perplexity beschreibt einen Index von „hunderten Milliarden Webseiten“. Die Dokumentation von Exa sagt, sein Lite-Modus liefere nur zwischengespeicherte Inhalte und rufe nie live ab.

Eigene Indizes können schnell antworten, entscheiden aber, was gecrawlt wird und wie oft. Live-Suche spiegelt wider, was eine Suchmaschine in diesem Moment zeigt. LLMWebSearch arbeitet auf die Live-Art: Die Ergebnisse stammen aus einer Live-Websuche, die im Moment Ihres Aufrufs ausgeführt wird, in der Reihenfolge, in der die Suchmaschine sie rankt; nichts wird aus einem alten Index geliefert.

Wie berechnen Web-Search-APIs ihre Preise?

Vier Modelle sind 2026 üblich, oft gemischt:

• Pro Suche. Ein Festpreis pro Aufruf, etwa 5 $ pro 1.000 bei Brave, Perplexity, Linkup oder You.com, gelesen am 22. Oktober 2026.
• Pro Credit. Tarife verkaufen Credits, und eine erweiterte Suche verbraucht mehr davon. Tavilys Basissuche kostet einen Credit, die erweiterte zwei.
• Pro Ergebnis oder pro Seite. Valyu berechnet pro zurückgegebenem Ergebnis; Firecrawl fügt einen Credit pro gelesener Seite hinzu.
• Pro Token. Jinas Suche berechnet mindestens 10.000 Tokens pro Anfrage.

Vergleichen Sie Gleiches mit Gleichem: Ein Preis, der vollen Seitentext enthält, ist nicht dasselbe Produkt wie ein Preis für Snippets. Der datierte Preisvergleich normalisiert sie.

Was sollte ich vor der Wahl prüfen?

Führen Sie zwanzig Ihrer echten Suchanfragen durch jeden Kandidaten aus und schauen Sie dann auf sieben Dinge:

• Inhalt. Ganze Seiten, auf die Suchanfrage fokussierte Auszüge oder nur Snippets?
• Aktualität. Können Sie nach Zeitraum filtern? Tragen Ergebnisse Daten?
• Kontrolle. Können Sie Ergebnisse, Seiten und Zeichen pro Seite begrenzen?
• Preis pro nützlicher Suche. Rechnen Sie die Reads ein, die Sie sonst separat zahlen würden.
• Abrechnungsbedingungen. Werden Credits monatlich zurückgesetzt oder übertragen? Sind eine Karte oder eine Arbeits-E-Mail erforderlich?
• Datenrechte. Dürfen Sie Ergebnisse speichern? Trainiert der Anbieter mit Ihren Suchanfragen?
• Site-Etikette. Respektiert der Reader robots.txt?

Für LLMWebSearch: Search-Credits verfallen nicht: Was Sie diesen Monat nicht verbrauchen, ist nächstes Jahr noch da. Wir trainieren kein Modell mit Ihren Suchanfragen oder mit dem, was die API zurückgibt, und wir stellen keine eigene Regel gegen das Speichern von Ergebnissen auf; die Rechte der Websites, deren Seiten Sie lesen, gelten weiterhin.