Plattform
Fehler
Fehler kommen als JSON im Format des aufgerufenen Endpoints zurück: mit einer verständlichen Meldung und bei Endpoints im OpenAI-Stil zusätzlich mit einem stabilen Code für Programme.
Das Format
{ "error": { "message": "This API key can't use `gpt-6-astra`. It's limited to gpt-6-sol. Change that at https://zurelay.com/app/keys.", "type": "permission_error", "param": "model", "code": "model_not_allowed" }}Bei /v1/messages kommen dieselben Fehler im Format von Anthropic zurück. Dieses hat keinen Code: Nutze den HTTP-Status und error.type: { "type": "error", "error": { "type": "...", "message": "..." } }. Jede Chat-, Bild- und Videoantwort hat einen x-request-id-Header, auch bei Fehlern.
Codes
Erneut versuchen
- Versuche
429und503erneut. Warte dabei die im Headerretry-afterangegebene Anzahl an Sekunden (oder verlängere die Wartezeit exponentiell), sofern die Antwort nichtx-should-retry: falsemeldet. - Versuche andere
4xx-Fehler nicht unverändert erneut: Sie schlagen wieder fehl. - Fehlgeschlagene Anfragen sind kostenlos. Wiederholte Versuche kosten also nichts, bis einer erfolgreich ist. Bei einem Stream, der mittendrin abbricht, wird berechnet, was er geliefert hat. Im seltenen Fall von
503mitx-should-retry: falsewird die Eingabe berechnet (siehe Abrechnung). - Die offiziellen SDKs von OpenAI und Anthropic wiederholen bei den passenden Fehlern bereits automatisch für dich.
Fehler mitten im Stream
Fehler, die ein Modell für deine Anfrage selbst zurückgibt (etwa wegen eines nicht unterstützten Parameters oder einer zu langen Eingabe), kommen mit der eigenen Meldung und dem eigenen Code des Modells als 400 oder 422 zurück.
Fehler mitten im Stream
Sobald ein Stream begonnen hat, kann ein Fehler nicht mehr als HTTP-Status zurückgegeben werden. Stattdessen erhältst du ein abschließendes Fehlerereignis (im Format des Endpunkts), und der Stream endet. Berechnet werden die Eingabe und die Ausgabe, die dich bis dahin erreicht hat – danach nichts mehr. Das ist selten: Die meisten Probleme werden vor dem ersten Token erkannt und durch einen erneuten Versuch behoben.
Ein solches Ereignis beendet auch einen Stream, wenn das Guthaben oder das Budget des Schlüssels mittendrin aufgebraucht ist, mit insufficient_quota, key_budget_exceeded oder key_daily_budget_exceeded. Eine nicht gestreamte Anfrage, bei der das mittendrin passiert, gibt die bis dahin erzeugte Ausgabe zurück – abgeschnitten wie eine Antwort, die max_tokens erreicht hat (finish_reason: "length" oder stop_reason: "max_tokens" bei /v1/messages) – mit einem x-zurelay-stopped-Header, der den Code nennt.
Fragen oder fehlt etwas? Frag unser Support-Team und wir antworten per E-Mail, meist innerhalb einer Minute.