Web Fetch
Geben Sie dem Modell den Volltext einer Seite, deren URL Sie bereits haben. Ein Tool-Eintrag genügt: Synthorai ruft die Seite ab, bereinigt sie und legt den lesbaren Text in die Unterhaltung — auf jedem Modell, über jeden Kanal.
Minimale Anfrage
Fügen Sie synthorai:web_fetch zu tools auf /v1/messages hinzu. Sonst ändert sich nichts:
curl https://synthorai.io/v1/messages \
-H "x-api-key: $YOUR_KEY" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-6",
"max_tokens": 1024,
"tools": [{"type": "synthorai:web_fetch"}],
"messages": [
{"role": "user", "content": "Summarise https://docs.anthropic.com/en/docs/build-with-claude/tool-use"}
]
}' Eine Seite wird nur abgerufen, wenn das Modell eine braucht und Sie synthorai:web_fetch eingeschlossen haben. Anfragen ohne das Tool sind gewöhnliche Anfragen — null Einfluss auf Verhalten oder Kosten.
Optionen
Jedes Feld des synthorai:web_fetch-Eintrags ist optional:
| Parameter | Beschreibung |
|---|---|
max_uses | Maximale Seitenabrufe pro Anfrage. Standard 3, gedeckelt bei 10. Es ist ein Ausgabenlimit und wird daher über Wiederholungen hinweg durchgesetzt — eine Anfrage mit max_uses: 1 zahlt höchstens einen Abruf, selbst wenn sie über Kanäle hinweg wiederholt wird. |
{
"type": "synthorai:web_fetch",
"max_uses": 2
} Zusammen mit Web Search
Die Suche findet Seiten; der Abruf liest sie. Deklarieren Sie beides, kann das Modell suchen, ein vielversprechendes Ergebnis wählen und die ganze Seite hereinholen — bei Recherchefragen ist das meist genau das Gewünschte:
"tools": [
{"type": "synthorai:web_search"},
{"type": "synthorai:web_fetch"}
] Antwortform
Jeder Abruf erscheint im Assistant-Zug als Blockpaar, gefolgt von der Antwort des Modells:
{
"type": "server_tool_use",
"id": "srvtoolu_synth_...",
"name": "web_fetch",
"input": { "url": "https://example.com/page" }
},
{
"type": "web_fetch_tool_result",
"tool_use_id": "srvtoolu_synth_...",
"content": {
"type": "web_fetch_result",
"url": "https://example.com/page",
"title": "Example page",
"content": { "type": "text", "text": "…page body…" }
}
} Die Zahl der Abrufe steht in usage — Sie können die Gebühr selbst abgleichen:
"usage": {
"input_tokens": 9241,
"output_tokens": 412,
"cache_read_input_tokens": 0,
"cache_creation_input_tokens": 0,
"server_tool_use": { "web_fetch_requests": 1 }
} Abrechnung
| Posten | Preis |
|---|---|
| Jede abgerufene Seite | $0.01 / Abruf |
| Tokens (Prompt + Completion) | Standard-Input-Preis des verwendeten Modells |
Die Gebühr pro Abruf ist nicht der ganze Preis. Eine abgerufene Seite geht als Eingabe-Tokens in die Unterhaltung ein, und ein langer Artikel kann mehrere Tausend davon sein — auf den meisten Modellen übersteigt dieser Token-Anteil die $0.01 Gebühr. Budgetieren Sie beides.
Drei Wege, es vorhersehbar zu halten:
- Setzen Sie
max_usesauf die kleinste Zahl, die Ihre Aufgabe braucht — sie deckelt die Gebühr der gesamten Anfrage, Wiederholungen inklusive. - Holen Sie gezielte Seiten, statt das Modell erkunden zu lassen. Eine vom Nutzer eingefügte URL ist ein Abruf; „rund ums Thema lesen" können drei sein.
- Beobachten Sie
usage.server_tool_use.web_fetch_requestsundusage.input_tokenszusammen — das Geld geht meist in Letzteres.
Grenzen und Sicherheit
- Nur
http- undhttps-URLs werden abgerufen. URLs mit eingebetteten Zugangsdaten werden abgelehnt. - Private, Loopback-, Link-Local- und Cloud-Metadaten-Adressen werden verweigert — web_fetch erreicht nur öffentliche Seiten.
- Seitentexte werden vor dem Eintritt in die Unterhaltung auf ein konfiguriertes Zeichenlimit gekürzt — eine einzelne Riesenseite kann eine Anfrage nicht grenzenlos aufblähen.
- Eine nicht abrufbare Seite kommt als Fehlerblock zurück, statt die ganze Anfrage scheitern zu lassen — das Modell kann darauf reagieren oder ohne die Seite antworten.
- Solange Sie
synthorai:web_fetchdeklarieren, ist der nackte Nameweb_fetchreserviert — ein eigenes Tool unter diesem Namen liefert ein400, das ihn benennt. Umbenennen oder densynthorai:-Parameter weglassen. - Ein Abruf, den wir vor Verlassen unseres Netzes ablehnen — abgelehnte URL, blockierte Domain, nicht konfiguriertes Backend — wird nicht berechnet. Ein Abruf, der den Anbieter erreichte und dort scheiterte, wird berechnet, weil der Anbieter uns berechnet hat. Beide zählen gegen
max_uses.
Ihre Verantwortung für das, was Sie abrufen
web_fetch ruft eine Seite auf Ihre Anweisung ab. Sie entscheiden, welche URL abgerufen wird — also verantworten Sie diesen Abruf und den Umgang mit dem, was zurückkommt.
- Sie müssen das Recht haben, auf den Inhalt zuzugreifen. Dazu gehören die Nutzungsbedingungen der Zielseite, ihre
robots.txt, jede Paywall- oder Login-Grenze sowie anwendbares Urheber- und Datenbankrecht. Der Abruf über uns verschafft Ihnen keinen Zugang, den Sie sonst nicht hätten. - Personenbezogene Daten bleiben Ihre Pflicht. Enthält eine abgerufene Seite persönliche Informationen, bleiben Sie deren Verantwortlicher nach DSGVO, PIPL und vergleichbaren Regimen — einschließlich Rechtsgrundlage, Speicherung und Löschverlangen.
- Ansprüche aus Ihren Abrufen sind Ihre. Erhebt ein Rechteinhaber oder Seitenbetreiber Ansprüche wegen von Ihnen abgerufener Inhalte, richten sie sich an Sie, und Sie tragen die Kosten. Das spiegelt die Bedingungen der vorgelagerten Abruf-Anbieter, über die wir routen.
- Modellausgaben sind nicht zur Weiterverwendung freigegeben. Eine auf abgerufenem Material aufgebaute Antwort kann Teile davon reproduzieren. Ob Sie diese Ausgabe erneut veröffentlichen dürfen, ist eine Frage der Quelllizenz — dazu machen wir keine Zusicherung.
Was an uns liegt: Wir betreiben die Abruf-Infrastruktur, blockieren interne und private Netzadressen, respektieren die von Ihrem Administrator konfigurierte Domain-Sperrliste und behalten abgerufene Seiteninhalte nicht über die Bearbeitung Ihrer Anfrage hinaus. Die Rechtmäßigkeit einzelner URLs prüfen wir nicht — und können es nicht: Eine URL allein trägt keine Lizenz.
Wir setzen web_fetch für einen API-Schlüssel aus, der glaubwürdige Missbrauchsmeldungen auf sich zieht oder von einem Abruf-Anbieter markiert wird — ein gesperrtes Anbieterkonto nimmt die Funktion für alle Kunden vom Netz.
FAQ
Kann das Modell eine Seite abrufen, die ich nicht erwähnt habe?
Es kann einer URL folgen, die es in derselben Unterhaltung über synthorai:web_search gefunden hat — genau das ist der Sinn der Kombination. Es ist angewiesen, keine URLs zu erfinden; muss es eine Seite finden, soll es zuerst suchen.
Was passiert, wenn die Seite hinter einem Login liegt oder Crawler blockiert?
Sie erhalten für diesen Abruf einen Fehlerblock, und das Modell macht ohne die Seite weiter. Der Abruf zählt trotzdem gegen max_uses, weil die Anfrage wirklich in Ihrem Auftrag gestellt wurde.
Ändert das Deklarieren des Tools etwas, wenn keine Seite abgerufen wird?
Nein. Abrechnung und Verhalten sind identisch mit einer normalen Anfrage, bis das Modell tatsächlich etwas abruft.