Kurzantwort: Wechseln Sie nicht bei jeder fehlgeschlagenen Anfrage von Claude zu GPT. Ein 401 bedeutet, dass die Authentifizierung korrigiert werden muss, und ein pfadbezogener 404 bedeutet, dass die URL oder der Endpunkt berichtigt werden muss. Ein 429 oder temporäre 5xx-Fehler können mit Backoff erneut versucht werden; wenn begrenzte Wiederholungen weiterhin scheitern, kann ein kompatibles Fallback-Modell übernehmen.
Eine wichtige Ausnahme: Eine 500-Antwort mit error.code: invalid_request bleibt ein Anfragenproblem. Ein erneuter Versuch – oder das Senden derselben fehlerhaften Nutzlast an ein anderes Modell – verschleiert den Bug lediglich.
Dieser Artikel wurde am 20. August 2026 gegen die CometAPI-Dokumentation zu Fehlern, Retries, Basis-URL, Rate Limits und Modell-Fallback verifiziert. Er behandelt ausschließlich die Fehlerklassifizierung. Für Routen-Design, Provider-Anmeldedaten und mehrschichtigen Failover nutzen Sie das vollständige Tutorial zum Modell-Fallback und den technischen Fallback-Leitfaden.
Beginnen Sie mit der Entscheidung: Wiederholen oder Abbrechen
| Status | Bedeutet in der Regel | Erneut versuchen? | Fallback? | Erste Maßnahme |
|---|---|---|---|---|
| 401 | Fehlender oder ungültiger API-Schlüssel | Nein | Nein | Bearer-Token korrigieren |
| 404 | Falscher Pfad oder Endpunkt | Nein | Nein | Basis-URL und Route prüfen |
| 429 | Rate Limit oder Auslastung | Ja | Nach begrenzten Retries | Mit Jitter drosseln |
| 500 + invalid_request | Fehlgebildete Anfrage | Nein | Nein | Payload korrigieren |
| 500/503/504/524 | Temporärer Plattform-/Providerfehler | Ja | Nach begrenzten Retries | Request-ID aufbewahren |
Die praktische Frage lautet nicht „Ist Claude fehlgeschlagen?“, sondern „Könnte ein anderes Modell ohne Änderung des ungültigen Teils dieser Anfrage erfolgreich sein?“ Authentifizierungs- und Pfadfehler betreffen die Verbindung selbst, daher kann ein Modellwechsel sie nicht lösen. Temporäre Kapazitäts- und Serverfehler können routenspezifisch sein, daher kann ein Fallback helfen.
Lesen Sie den Fehler, bevor Sie das Modell wechseln
Nutzen Sie den HTTP-Status zusammen mit error.code und error.message. Viele CometAPI-Fehler verwenden einen Umschlag wie diesen:
{
"error": {
"message": "human-readable detail and request id",
"type": "comet_api_error",
"param": "problematic_parameter_or_empty",
"code": "error_code_or_empty"
}
}
Klassifizieren Sie nicht nur nach der ersten Ziffer des Statuscodes. Ein 500 kann weiterhin invalid_request enthalten, während ein falscher CometAPI-Pfad eine Weiterleitung oder HTML statt eines sauberen JSON-404 liefern kann.
401 Unauthorized: Anhalten und Authentifizierung beheben
Ein 401 bedeutet in der Regel, dass der API-Schlüssel fehlt, fehlerhaft formatiert, abgelaufen oder aus der falschen Umgebung geladen wurde. Der Header muss lauten:
Authorization: Bearer $COMETAPI_KEY
Keine Retries und kein Modellwechsel. Beide Routen verwenden dieselbe fehlerhafte Authentifizierung. Prüfen Sie, ob der deployte Dienst ein altes Secret geladen hat, ob dem Schlüssel Leerzeichen hinzugefügt wurden und ob die Anfrage die vorgesehene Umgebung erreicht. Rotieren oder laden Sie den Schlüssel ausschließlich über Ihren Secret-Management-Prozess.
404 Not Found: URL korrigieren, bevor Fallback erfolgt
Für OpenAI-kompatible Anfragen verwenden Sie genau diese Basis-URL:
https://api.cometapi.com/v1
Ein fehlendes /v1, ein doppeltes Pfadsegment oder der falsche Endpunkt können 404, eine Weiterleitung, eine HTML-Antwort oder einen SDK-Parsing-Fehler erzeugen. Deaktivieren Sie beim Debugging das automatische Folgen von Weiterleitungen und bestätigen Sie den endgültigen Anfragepfad anhand der API-Referenz.
Wenn die Antwort explizit angibt, dass ein Modell nicht verfügbar ist oder nicht gefunden wurde, verifizieren Sie die Modell-ID in der aktuellen CometAPI Models API. Behandeln Sie nicht jeden 404 als Modell-Unverfügbarkeit. Fügen Sie erst dann ein modellspezifisches Fallback hinzu, nachdem Sie genau dieses Signal erfasst und getestet haben.
429 Too Many Requests: Drosseln, bevor Sie auf Fallback umschalten
Ein 429 ist retry-fähig. Nutzen Sie exponentielles Backoff mit Jitter, senken Sie die Burst-Konkurrenz und messen Sie, welche Route gesättigt ist. Ein sofortiger Retry aller Worker kann ein kurzes Rate Limit in einen größeren Traffic-Peak verwandeln.
Nach einer kleinen, begrenzten Anzahl an Retries kann Fallback sinnvoll sein, wenn das nächste Modell denselben Input, denselben Output-Vertrag und die erforderlichen Fähigkeiten unterstützt. Fallback ist nicht kostenlos: Es erhöht die Latenz und kann Kosten oder Verhalten ändern, daher sollten Sie erfassen, wie oft es verwendet wird.
5xx-Fehler: Code prüfen, dann erneut versuchen
500, 503, 504 und 524 stehen häufig für Plattform-, Provider- oder Timeout-Klassenfehler. Bewahren Sie Request-ID, Endpunkt, Modell und Zeitstempel auf und versuchen Sie es dann mit Backoff erneut. Wenn derselbe transiente Fehler die Retry-Budgets übersteht, wechseln Sie zur nächsten kompatiblen Route.
Prüfen Sie jedoch zuerst den Body. Wenn ein 500 error.code: invalid_request oder invalid_request_error enthält, korrigieren Sie den Request-Body und versuchen Sie es erst nach einer Änderung erneut. Häufige Ursachen sind ein fehlendes messages-Feld oder ein providerspezifischer Parameter, den der ausgewählte Endpunkt nicht akzeptiert.
Eine kleine Richtlinie im Code verwenden
Dieses Python-Beispiel hält Retries und Fallback in der Applikation. Es verwendet einen CometAPI-Schlüssel, die OpenAI-kompatible Basis-URL und Umgebungsvariablen für die aktuellen Claude- und GPT-Modell-IDs. Es wiederholt nur bei transienten Fehlern und ändert nach Ausschöpfen des Retry-Budgets die Modelle.
import os, random, time
from openai import APIError, OpenAI
client = OpenAI(
api_key=os.environ["COMETAPI_KEY"],
base_url="https://api.cometapi.com/v1",
max_retries=0,
)
MODELS = [os.environ["CLAUDE_MODEL"], os.environ["GPT_MODEL"]]
RETRYABLE = {429, 500, 503, 504, 524}
def complete(messages):
for model in MODELS:
for attempt in range(3):
try:
response = client.chat.completions.create(model=model, messages=messages)
return response.choices[0].message.content
except APIError as error:
status = getattr(error, "status_code", None)
code = getattr(error, "code", None)
if status in {401, 404} or code in {
"invalid_request", "invalid_request_error"
}:
raise
if status not in RETRYABLE:
raise
if attempt < 2:
time.sleep(2**attempt + random.random())
continue
break
raise RuntimeError("No configured route completed.")
print(complete([{"role": "user", "content": "Summarize this ticket."}]))
Die automatischen Retries des SDK sind deaktiviert, damit die Applikation das gesamte Retry- und Fallback-Budget steuert. Ohne diese Kontrolle können sich SDK-Retries und Applikations-Retries multiplizieren und die finale Antwort verzögern.
Testen Sie die Richtlinie ohne Raten
| Simuliertes Signal | Erwartetes Ergebnis | Was nicht passieren darf |
|---|---|---|
| 401 | Sofort fehlschlagen | Kein Retry und kein GPT-Aufruf |
| 404 | Sofort fehlschlagen | Kein Fallback, der falschen Pfad verdeckt |
| 429 | Drosseln, dann Fallback | Kein sofortiger Retry-Sturm |
| 500 + invalid_request | Sofort fehlschlagen | Keine doppelte fehlerhafte Anfrage |
| 503/504/524 | Drosseln, dann Fallback | Keine unbegrenzte Routenkette |
Dies sind Richtlinientests, keine Aussagen über die Zuverlässigkeit realer Provider. Injizieren Sie in der Staging-Umgebung Status und Error-Body in den Klassifizierer, verifizieren Sie Anzahl und Reihenfolge der Aufrufe und bestätigen Sie, dass Ihr finaler Fehler weiterhin den ursprünglichen Anfragekontext enthält.
Wann Claude-zu-GPT-Fallback tatsächlich sicher ist
Der Wechsel zwischen Modellfamilien ist nur sicher, wenn beide Routen denselben Applikationsvertrag erfüllen können. Normalisieren Sie Request- und Response-Felder, testen Sie strukturierten Output oder Tool-Verhalten auf beiden Modellen und verifizieren Sie jede erforderliche Bild-, Dokument-, Kontext- oder Reasoning-Fähigkeit, bevor Sie die Route aktivieren.
Fallback sollte auch Seiteneffekte berücksichtigen. Wenn die erste Route bereits ein Tool ausgelöst, Daten geschrieben oder eine teilweise Antwort gestreamt hat, kann ein blindes Wiederholen der gesamten Anfrage Aktionen duplizieren oder Nutzer verwirren. Setzen Sie an einem Checkpoint fort oder liefern Sie stattdessen einen kontrollierten Fehler zurück.
Produktionsprüfungen, die Retries begrenzen
- Setzen Sie ein einziges Gesamt-Latenzbudget. Zählen Sie jeden Retry und jeden Fallback-Versuch gegen dieselbe Frist.
- Begrenzen Sie Retries. Nutzen Sie Backoff mit Jitter und stoppen Sie nach einem kleinen, konfigurierten Limit.
- Steuern Sie die Konkurrenz. Reduzieren Sie Bursts, bevor Anfragen die Applikation verlassen.
- Fügen Sie einen Circuit Breaker hinzu. Stoppen Sie temporär eine Route, die wiederholt scheitert.
- Protokollieren Sie Entscheidungen. Erfassen Sie Status, Error-Code, Request-ID, Modell, Versuch, Verzögerung und Fallback-Grund ohne Secrets zu speichern.
- Verfolgen Sie die Fallback-Rate. Ein anhaltender Anstieg ist ein operatives Signal, kein normales Erfolgsmaß.
Häufig gestellte Fragen
Sollte ein 401 jemals einen Modelfallback auslösen?
Nein. Korrigieren oder laden Sie den API-Schlüssel neu. Ein anderes Modell, das mit denselben ungültigen Anmeldedaten aufgerufen wird, scheitert aus demselben Grund.
Sollte ein 404 Fallback auslösen?
Nicht standardmäßig. Korrigieren Sie zuerst die Basis-URL oder den Endpunkt. Nur ein separat verifiziertes Signal „Modell nicht verfügbar“ sollte in den Fallback-Klassifizierer einfließen.
Wie oft sollte ich einen 429 erneut versuchen?
Verwenden Sie ein kleines, applikationsdefiniertes Limit, das in das nutzerseitige Latenzbudget passt. Nutzen Sie Backoff mit Jitter und reduzieren Sie die Konkurrenz; keine sofortigen oder unbegrenzten Retries.
Sind alle 5xx-Fehler retry-fähig?
Nein. Temporäre 500, 503, 504 und 524 sind Kandidaten für Retries, aber 500 mit invalid_request sollte hart fehlschlagen, bis die Payload korrigiert ist.
Können Claude und GPT dieselbe unveränderte Anfrage verwenden?
Nur für die gemeinsamen Felder, die Ihre Applikation getestet hat. Providerspezifische Parameter, Tool-Formate, strukturierte Outputs und multimodale Inputs können Adapter erfordern. Eine reine Modell-ID-Änderung beweist keine Kompatibilität.
Wo ist die vollständige Fallback-Implementierung?
Siehe How to Build Robust LLM Model Fallback Strategies für die übergeordnete Architektur und den CometAPI model fallback guide für Implementierungsdetails.
Machen Sie den Fehlerklassifizierer zum Gatekeeper
Automatisches Fallback ist nützlich, wenn es eng und beobachtbar ist. Lassen Sie Authentifizierungs-, Pfad- und fehlgebildete Anfragen laut fehlschlagen. Wiederholen Sie Rate-Limits und temporäre Serverfehler mit Backoff und wechseln Sie erst nach Ausschöpfen des Retry-Budgets zu einer kompatiblen Route. Diese Richtlinie macht Fallback zu einer Zuverlässigkeitskontrolle statt zu einem Mittel, Konfigurationsfehler zu kaschieren.