Websuche und Webabruf per API: Was $0.01 bringen

Alle großen Tools für serverseitige Websuche verlangen inzwischen dieselbe Gebühr: $0.01 pro Suche. Auf der Rechnung ist das der uninteressanteste Posten. Bei unseren Messungen fügte jede Suche der Anfrage 1.500 bis 3.100 Ergebnistoken hinzu. Sie werden zum Input-Preis des verwendeten Modells abgerechnet. Was im nächsten Turn passiert, hängt von einem Protokolldetail ab, das viele Teams übersehen: Übernimmt der Endpoint die Suchbelege in den nächsten Turn, oder verwirft er sie stillschweigend, sodass das Modell auf deine Kosten erneut suchen muss? Wir haben synthorai:web_search und synthorai:web_fetch von Synthorai mit vier Modellfamilien gemessen und die Ergebnisse mit den veröffentlichten Preisen von Anthropic und OpenAI für deren gehostete Suche verglichen.

TL;DR

• Bei Synthorai, Anthropic und OpenAI kostet jede Suche $0.01; in den Abrechnungsdaten erscheint sie einzeln mit $0.0100.
• Eine Suche fügt 1.500–3.100 Ergebnistoken zum Input-Preis des Modells ein. Bei günstigen Modellen dominiert die Gebühr, bei Premium-Modellen machen die Token bis zur Hälfte aus.
• max_uses ist ein Limit, kein Kontingent: Obwohl 10 Suchen erlaubt waren, stoppte das Modell nach 3. Die Gebühren richten sich nach den tatsächlich ausgeführten Suchen.
• Im zweiten Turn unterscheiden sich die Endpoints: /v1/messages übernimmt die Ergebnisse (≈3.900 Token, keine neue Gebühr); /v1/chat/completions verwirft sie. Braucht ein Follow-up Belege, wird daher eine neue Suche fällig.

Warum brauchen Modelle überhaupt Websuche und Webabruf?

Weil das Wissen eines Modells am Trainingsstichtag endet, die meisten Fragen aus der Produktion aber nicht. Preise, Release Notes, Wechselkurse, Sportergebnisse oder der Inhalt einer URL, die ein Nutzer gerade eingefügt hat: Nichts davon steckt in den Gewichten. Wer trotzdem selbstsicher antwortet, liefert halluzinierte „aktuelle“ Fakten aus. Die Websuche schließt diese Lücke bei der Recherche, wenn das Modell nicht weiß, wo die Antwort steht. Der Webabruf übernimmt das Lesen, wenn die genaue Seite bekannt ist und nur ihr Inhalt benötigt wird. Beides lässt sich mit einer Search API, einem Scraper und einem Tool-Calling-Loop selbst bauen, und viele Teams tun das. Serverseitige Varianten gibt es, weil dieser Loop reine Infrastrukturarbeit ist. Läuft er beim Provider, entfallen Roundtrips, Parsing-Code und zusätzlicher Betriebsaufwand. Die Gebühr ist dabei inzwischen überall gleich.

Wie funktioniert serverseitige Websuche?

Der gesamte Loop läuft innerhalb einer einzigen API-Anfrage. Genau darin liegt der Vorteil. Bei clientseitigen Tools fordert das Modell deinen Code zu einer Suche auf, dein Code sendet die Ergebnisse zurück, und bei jedem Schritt wird die Konversation erneut übertragen. Ein Server-Tool nimmt deinen Code aus diesem Ablauf heraus: Du deklarierst {"type": "synthorai:web_search"} unter tools, das Modell erzeugt eine Suchanfrage, das Gateway leitet sie an einen spezialisierten Suchanbieter weiter, fügt die Ergebnisse in den Modellkontext ein und lässt das Modell daraus eine Antwort erstellen. Bis zum Limit max_uses kann es auch erneut suchen. Eine Anfrage geht hinein, eine Antwort mit Quellenangaben und Abrechnung kommt zurück.

In einer normalen Anfrage genügt eine Zeile. Loop-Code und Callbacks sind nicht nötig:

curl https://synthorai.io/v1/chat/completions \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash-0731",
    "messages": [{"role": "user", "content": "What is one AI news headline from this week? Name the source."}],
    "tools": [{"type": "synthorai:web_search", "max_uses": 1}]
  }'

Für den Webabruf wird lediglich ein anderer Typ deklariert. Die URL steht in der Nachricht, das Gateway ruft die Seite ab:

"messages": [{"role": "user", "content": "Fetch https://example.com/pricing and summarize the tiers."}],
"tools": [{"type": "synthorai:web_fetch", "max_uses": 1}]

Das Diagramm zeigt exakt die oben stehende Suchanfrage, gemessen mit deepseek-v4-flash-0731. Erfasst wurden 2.059 Input-Token, bestehend aus einer Frage mit 30 Token und rund 2.000 Token eingefügter Ergebnisse, außerdem 169 Output-Token und Gesamtkosten von $0.0104. Davon entfielen $0.01 auf die Suchgebühr und etwa $0.0004 auf Token. Es gibt genau zwei Abrechnungsposten: die Gebühr bei Ausführung der Suche und die Ergebnistoken zum regulären Input-Preis des Modells. Ein Abruf wird genauso abgerechnet; an die Stelle der Snippets tritt die abgerufene Seite.

Die Deklaration selbst ist kostenlos. Wenn eine Anfrage das Tool deklariert, aber keine Suche ausführt, fällt keine Gebühr an. Das Tool funktioniert mit jedem Modell im Katalog. Darin liegt der strukturelle Unterschied zu den First-Party-Angeboten: Die gehostete Suche von Anthropic bedient Claude-Modelle, die von OpenAI nur OpenAI-Modelle. Ein Tool auf Gateway-Ebene funktioniert mit jedem Modell, an das du die Anfrage routest.

Was kostet eine Suche tatsächlich?

Zur Gebühr von $0.01 kommen Tokenkosten hinzu. Je teurer das Modell, desto stärker verschiebt sich der Anteil zu den Token. Wir haben dieselbe Nachrichtenfrage mit einer Suche für jede der vier Modellfamilien dreimal ausgeführt. Die exakten Tokenpreise der Modelle wurden aus Baselines ohne Tools ermittelt, die Gebühr als Restbetrag abgelesen:

Beim günstigsten Modell macht die Suchgebühr 97% des Calls aus. Bei Premium-Modellen entfällt etwa die Hälfte der Rechnung auf die eingefügten Token. Die Gebühr ist nicht nur aus den Gesamtkosten abgeleitet: In unseren Abrechnungsdaten erscheint das Tool mit exakt $0.0100 pro Call als eigene Position, getrennt von den durch das Tool eingefügten Token. Bei einem realen Abruf waren das beispielsweise 3.454 von insgesamt 3.836 Input-Token. Inklusive aller Kosten lag eine einzelne Suche je nach Modell zwischen $0.010 und $0.012. Wer mit dem oberen Ende dieser Spanne kalkuliert, erlebt keine Überraschungen. Praktisch bedeutet das: Bei einem günstigen Modell ist die serverseitige Suche das eigentliche Produkt, während die Modellkosten kaum ins Gewicht fallen.

Welche drei Faktoren bestimmen die Tokenkosten?

Anzahl der Suchen, Länge der Ergebnisse und Umfang der Seite. Alles andere fällt kaum ins Gewicht. Jeder dieser Faktoren lässt sich direkt messen, zwei davon kannst du unmittelbar steuern.

Faktor eins: Anzahl der ausgeführten Suchen. max_uses ist eine Obergrenze, kein Sollwert. Bei einer Frage zu den Preisen von fünf Anbietern ergaben Limits von 1, 2 und 3 Suchen Kosten von $0.0106, $0.0216 und $0.0319. Die Gebühren stiegen linear um $0.01 pro tatsächlich ausgeführter Suche. Ein Limit von 5 oder sogar 10 änderte nichts, weil das Modell selbstständig nach drei Suchen stoppte. Nicht genutzter Spielraum kostet nichts, genau wie bei den von uns gemessenen Thinking-Budgets für Reasoning-Modelle. Der Standardwert liegt bei 3, die harte Obergrenze bei 10. Ohne Konfiguration entstehen bei einer suchintensiven Frage im Worst Case also drei Gebühren plus drei Ergebnisladungen. Für Routen mit einzelnen Fakten sollte max_uses: 1 gesetzt werden.

Faktor zwei: Länge der Ergebnisse. Die Größe der eingefügten Daten hängt vom Umfang der Frage ab, nicht vom Zufall. In zwölf Läufen mit jeweils einer Suche auf deepseek-v4-flash-0731 ergaben sich folgende Werte:

Eng gefasste Fragen liefern kompakte Ergebnismengen. Vergleichsfragen fallen breiter aus und erzeugen etwa 45% mehr Token als eine einzelne Faktenfrage. Für die Budgetierung decken 2.000 Token pro Suche mit einer Spanne von 20% alle unsere Messungen ab. Bei üblichen Modellpreisen entspricht die Tokenkomponente einer Suche damit zwischen einem Zwanzigstel und der Hälfte der Gebühr von $0.01.

Faktor drei: Umfang der abgerufenen Seite. Die Abrufgebühr bleibt gleich; den Rest bestimmt die Seite. Unsere Messreihe lief vollständig über dasselbe Modell:

Mit einem günstigen Modell kostet selbst der Wikipedia-Artikel nur knapp anderthalb Cent. Wird derselbe Abruf über ein Modell für $2 pro Million Token geroutet, kostet diese eine Seite sechseinhalb Cent und damit das Fünffache der Gebühr. Für die Budgetplanung ist außerdem relevant, dass dieselbe Seite je nach Modellfamilie unterschiedlich tokenisiert wird. Der datenreiche Beitrag umfasste bei DeepSeek 5.196 Token und bei qwen3.8-max 5.508 Token. Dieser Aufschlag von 6% beim Tokenizer entspricht unseren Messungen zur Tokendichte.

Was passiert im nächsten Turn mit den Suchergebnissen?

Die beiden API-Protokolle unterscheiden sich hier grundlegend. Davon hängen die Kosten des Follow-ups ab. Das Protokoll von /v1/messages definiert einen Assistant-Turn als Liste von Content-Blöcken. Aktivitäten von Server-Tools gehören daher zum offiziellen Verlauf des Turns: Die Antwort enthält server_tool_use, danach web_search_tool_result und schließlich Text. Im nächsten Turn erwartet das Protokoll diese Blöcke erneut. Die Belege werden also bewusst als Input-Token übernommen. Bei /v1/chat/completions besteht eine Assistant-Nachricht dagegen aus einem einzigen Content-String ohne Platz für Ergebnisse von Server-Tools. Die eingefügten Resultate werden serverseitig verarbeitet; im Verlauf bleibt nur die sichtbare Antwort, die Belege gehen verloren.

Wir haben dasselbe Paar aus Suche und Follow-up mit claude-sonnet-5 über beide Schnittstellen ausgeführt. Über /v1/messages wurden für das Follow-up 3.911 Input-Token und $0.0109 berechnet, vollständig als Tokenkosten. Eine neue Suche war nicht nötig, weil das Modell weiterhin auf die Ergebnisse zugreifen konnte. Über /v1/chat/completions kostete das Follow-up $0.0204 und damit mehr als die erneute Übertragung. Das Modell hatte nur noch seine eigene einzeilige Zusammenfassung und führte deshalb eine neue Suche aus: erneut $0.01 Gebühr plus eine neue Ergebnisladung. Eine solche Neusuche ist jedoch nicht zwingend. In einem früheren Lauf desselben absorbierenden Follow-ups mit deepseek-v4-flash-0731 genügte die Zusammenfassung. Der Call umfasste 460 Input-Token und kostete $0.00009. Bei der Absorption gibt es für Follow-ups daher zwei typische Kostenprofile: nahezu kostenlos, wenn die Zusammenfassung reicht, oder Gebühr plus Ergebnisladung, wenn das Modell erneut im Web sucht.

Keiner der beiden Endpoints ist pauschal günstiger; die Kosten fallen lediglich an unterschiedlichen Stellen an. Der blockbasierte Stil zahlt in jedem Turn vorhersagbare Tokenkosten und kauft bereits vorhandene Belege nie erneut. Der absorbierende Stil setzt darauf, dass Follow-ups ohne diese Belege auskommen, und verursacht bei einer Fehleinschätzung eine neue Gebühr. Chats mit vielen Turns und oberflächlichen Follow-ups passen gut zu /v1/chat/completions. Für Recherche-Agenten, die Quellen genauer auswerten, eignet sich /v1/messages. Dort lässt sich die Schichtung des Prompt Cache auf übernommene Ergebnisse genauso anwenden wie auf jeden anderen großen Kontext.

Was verlangen Anthropic und OpenAI, und wo laufen ihre Tools?

Der Preisvergleich ist schnell erledigt: Alle verlangen $0.01 pro Suche. Der Rest richtet sich nach dem Tokenpreis des Modells. Anthropic berechnet $10 pro 1.000 Suchen und behandelt die Ergebnisse als Input-Token. Der Webabruf ist dort gebührenfrei; nur die Token werden berechnet. OpenAI verlangt ebenfalls $10 pro 1.000 Aufrufe, wobei die Behandlung der Token von der Modellstufe abhängt. Die Gebühr steht fest. Variabel ist der Input-Preis des Modells für 1.500–3.100 eingefügte Token.

Der eigentliche Unterschied steht nicht in der Preistabelle, sondern betrifft den Ausführungsort der Tools. First-Party-Server-Tools sind für die Agent-Stacks ihrer Anbieter gebaut und bleiben an deren eigene Schnittstellen gebunden. Laut Anthropic-Dokumentation ist die Websuche nicht auf Amazon Bedrock verfügbar. Google Cloud unterstützt nur die Basissuche, und Microsoft Foundry setzt ein bei Anthropic gehostetes Deployment voraus. Der Webabruf ist weder über Bedrock noch über Google Cloud verfügbar. Die Suche von OpenAI ist an die Responses API gekoppelt. Wenn ein Workload eine Cloud-Grenze oder Modellfamilie wechselt, bleibt das First-Party-Tool zurück. Aus demselben Grund reicht ein Gateway diese Tools nicht einfach durch: Sie können dem Traffic nicht folgen. Ein Tool auf Gateway-Ebene wählt den umgekehrten Ansatz. Eine Deklaration funktioniert auch nach einem Modell- oder Plattformwechsel weiter.

FAQ

Wie viel kostet die Websuche per API pro Anfrage?

Für jede ausgeführte Suche fallen $0.01 an. In den Abrechnungsdaten erscheint die Gebühr als eigene Position. Hinzu kommen die eingefügten Ergebnisse als Input-Token zum Preis des jeweiligen Modells; bei unseren Messungen waren das 1.500–3.100 Token pro Suche. Wenn eine Anfrage das Tool nur deklariert, aber keine Suche ausführt, fällt keine Gebühr an. Für typische Modelle solltest du mit Gesamtkosten von $0.010–0.012 pro Suche rechnen. Bei sehr günstigen Modellen macht die Gebühr 97% der Gesamtkosten aus.

Werden Suchergebnisse in späteren Turns erneut berechnet?

Das hängt vom Endpoint ab. Bei /v1/messages werden die Ergebnisblöcke mit dem Verlauf erneut übertragen. In unseren Läufen waren das etwa 3.900 Input-Token pro Turn, ohne zusätzliche Suchgebühr. Bei /v1/chat/completions werden die Ergebnisse nach dem Turn absorbiert. Kann das Modell das Follow-up aus seiner Zusammenfassung beantworten, ist der Call fast kostenlos; in einem Lauf waren es $0.00009. Sucht es erneut, fallen eine neue Gebühr und eine neue Ergebnisladung an; in einem anderen Lauf waren es $0.0204. Anthropic dokumentiert die erneute Übertragung als Standardverhalten seiner eigenen Suche. Dort werden die Ergebnisse in jedem Turn erneut als Token berechnet.

Wie begrenze ich die Ausgaben für Websuche pro Anfrage?

Mit max_uses. Das Modell kann diese harte Obergrenze nicht überschreiten. Der Standardwert ist 3, das Maximum 10. Gebühren fallen nur für tatsächlich ausgeführte Suchen an; ungenutzter Spielraum ist kostenlos. Bei Routen für einzelne Fakten begrenzt max_uses: 1 den Worst Case auf eine Gebühr plus eine Ergebnisladung.

Wann sollte ich den Webabruf statt der Websuche verwenden?

Nutze den Abruf, wenn die URL bereits bekannt ist und du die vollständige Seite benötigst. Die Suche eignet sich, wenn die Quelle erst gefunden werden muss. Über das Gateway kosten beide $0.01 pro Nutzung. Ein Abruf fügt jedoch die gesamte Seite ein: in unserer Messreihe von 209 Token für eine minimale Seite bis zu 27.380 Token für einen langen Artikel. Eine Suche fügt dagegen Snippets aus mehreren Quellen ein. Für Pipelines, die Seiten mit Claude-Modellen abrufen und zusammenfassen, ist das eigene Fetch-Tool von Anthropic gebührenfrei und damit günstiger.

Gemessen am 2026-08-10 über das Synthorai-Gateway mit synthorai:web_search und synthorai:web_fetch auf deepseek-v4-flash-0731, gpt-5.6-luna, qwen3.8-max und claude-sonnet-5: Die Tokenpreise pro Modell wurden aus Baselines ohne Tools mit je zwei Messpunkten ermittelt. Die Suchgebühren ergeben sich als Restbetrag der abgerechneten Kosten nach Abzug des Tokenwerts (n=3 pro Modell). Zusätzlich umfassten die Messungen eine max_uses-Reihe, eine Auswertung der Ergebnisgröße nach Anfragetyp (4 Typen x 3 Läufe), Follow-up-Tests auf beiden Endpoints mit identischen Fragen sowie eine Abrufreihe mit fünf Seiten, darunter drei eigene Seiten, eine minimale externe Seite und ein langer Artikel. Die Gebühren wurden anhand detaillierter Abrechnungsdaten mit separaten Positionen für Tool-Aufruf und eingefügte Tool-Token bestätigt und nicht allein aus den Gesamtkosten abgeleitet. Die Werte für Anthropic und OpenAI stammen aus deren veröffentlichter Dokumentation zum Publikationszeitpunkt. Die Zahlen im Diagramm entsprechen einem einzelnen, unverändert übernommenen Messlauf. Gebühren und Verhalten können sich ändern; prüfe sie anhand deiner eigenen Nutzungsdaten.

← Zurück zum Blog