Réponse courte : ne basculez pas de Claude à GPT pour chaque requête échouée. Un 401 signifie que l’authentification doit être corrigée, et un 404 lié au chemin signifie que l’URL ou l’endpoint doit être corrigé. Un 429 ou un 5xx temporaire peut être retenté avec backoff ; si des réessais bornés échouent toujours, un modèle de repli compatible peut prendre le relais.
Il y a une exception importante : une réponse 500 avec error.code: invalid_request reste un problème de requête. La retenter — ou envoyer la même charge utile cassée à un autre modèle — ne fait que masquer le bug.
Cet article a été vérifié le 20 août 2026 par rapport à la documentation de CometAPI sur les erreurs, les réessais, la base URL, les limites de débit et le repli de modèle. Il couvre uniquement la classification des erreurs. Pour la conception des routes, les identifiants de fournisseur et le basculement multi-couches, utilisez le tutoriel complet sur le repli de modèle et le guide technique de repli.
Commencez par décider: réessayer ou échouer
| Statut | Signifie généralement | Réessayer ? | Repli ? | Première action |
|---|---|---|---|---|
| 401 | Clé manquante ou invalide | Non | Non | Corriger le bearer token |
| 404 | Mauvais chemin ou endpoint | Non | Non | Vérifier la base URL et la route |
| 429 | Limite de débit ou saturation | Oui | Après des réessais bornés | Backoff avec gigue |
| 500 + invalid_request | Requête malformée | Non | Non | Corriger la charge utile |
| 500/503/504/524 | Panne temporaire plateforme/fournisseur | Oui | Après des réessais bornés | Conserver l’ID de requête |
La question pratique n’est pas « Claude a-t-il échoué ? » mais « Un autre modèle pourrait-il réussir sans changer la partie invalide de cette requête ? ». Les erreurs d’authentification et de chemin affectent la connexion elle-même, donc changer de modèle ne peut pas les résoudre. Les pannes temporaires de capacité et de serveur peuvent être spécifiques à une route ; un repli peut aider.
Lisez l’erreur avant de changer de modèle
Utilisez le statut HTTP avec error.code et error.message. De nombreuses défaillances CometAPI utilisent une enveloppe comme ceci :
{
"error": {
"message": "human-readable detail and request id",
"type": "comet_api_error",
"param": "problematic_parameter_or_empty",
"code": "error_code_or_empty"
}
}
Ne classez pas uniquement par le premier chiffre du code de statut. Un 500 peut encore porter invalid_request, tandis qu’un mauvais chemin CometAPI peut renvoyer une redirection ou du HTML au lieu d’un 404 JSON propre.
401 Unauthorized: arrêtez et corrigez l’authentification
Un 401 signifie généralement que la clé API est manquante, malformée, expirée, ou chargée depuis le mauvais environnement. L’en-tête doit être :
Authorization: Bearer $COMETAPI_KEY
Ne réessayez pas et ne changez pas de modèle. Les deux routes utilisent la même authentification cassée. Vérifiez si le service déployé a chargé un ancien secret, si des espaces ont été ajoutés à la clé, et si la requête atteint l’environnement prévu. Faites tourner ou rechargez la clé uniquement via votre processus de gestion des secrets.
404 Not Found: corrigez l’URL avant le repli
Pour les requêtes compatibles OpenAI, utilisez exactement cette base URL :
https://api.cometapi.com/v1
Un /v1 manquant, un segment de chemin dupliqué, ou un mauvais endpoint peut produire un 404, une redirection, une réponse HTML, ou une erreur d’analyse du SDK. Désactivez le suivi automatique des redirections pendant le débogage et confirmez le chemin final de la requête avec la référence API.
Si la réponse indique explicitement qu’un modèle est indisponible ou introuvable, vérifiez l’ID du modèle dans l’API Models CometAPI actuelle. Ne traitez pas chaque 404 comme une indisponibilité de modèle. Ajoutez un repli spécifique au modèle uniquement après avoir capturé et testé ce signal exact.
429 Too Many Requests: reculez avant d’échouer vers un repli
Un 429 est réessayable. Utilisez un backoff exponentiel avec gigue, réduisez la concurrence en rafale, et mesurez quelle route est saturée. Un réessai immédiat par chaque worker peut transformer une courte limite de débit en un plus grand pic de trafic.
Après un petit nombre de réessais bornés, un repli peut être approprié lorsque le modèle suivant prend en charge la même entrée, le même contrat de sortie et les capacités requises. Le repli n’est pas gratuit : il ajoute de la latence et peut changer le coût ou le comportement ; consignez sa fréquence d’utilisation.
Erreurs 5xx : vérifiez le code, puis réessayez
Les 500, 503, 504 et 524 représentent souvent des pannes de plateforme, de fournisseur ou des échecs de type timeout. Conservez l’ID de la requête, l’endpoint, le modèle et l’horodatage, puis réessayez avec backoff. Si la même panne transitoire persiste au-delà du budget de réessais, passez à la route compatible suivante.
Mais inspectez d’abord le corps. Lorsqu’un 500 contient error.code: invalid_request ou invalid_request_error, corrigez le corps de la requête et ne réessayez qu’après modification. Les causes courantes incluent un champ messages manquant ou un paramètre spécifique au fournisseur que l’endpoint sélectionné n’accepte pas.
Utilisez une petite politique unique dans le code
Cet exemple Python maintient les réessais et le repli dans l’application. Il utilise une seule clé CometAPI, la base URL compatible OpenAI, et des variables d’environnement pour les ID de modèle Claude et GPT actuels. Il ne réessaie que les défaillances transitoires, puis change de modèle après l’épuisement du budget de réessais.
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."}]))
Les réessais automatiques du SDK sont désactivés afin que l’application maîtrise le budget total de réessais et de repli. Sans ce contrôle, les réessais du SDK additionnés aux réessais de l’application peuvent multiplier les appels et retarder la réponse finale.
Testez la politique sans deviner
| Signal simulé | Résultat attendu | Ce qui ne doit pas arriver |
|---|---|---|
| 401 | Lever immédiatement | Aucun réessai et aucun appel GPT |
| 404 | Lever immédiatement | Aucun repli masquant un mauvais chemin |
| 429 | Backoff, puis repli | Pas de déluge de réessais immédiats |
| 500 + invalid_request | Lever immédiatement | Pas de requête cassée en double |
| 503/504/524 | Backoff, puis repli | Pas de chaîne de routes non bornée |
Ce sont des tests de politique, pas des affirmations sur la fiabilité réelle des fournisseurs. En préproduction, injectez le statut et le corps d’erreur dans le classificateur, vérifiez le nombre et l’ordre des appels, et confirmez que votre erreur finale inclut encore le contexte de la requête d’origine.
Quand le repli Claude-vers-GPT est réellement sûr
Changer de famille de modèles n’est sûr que lorsque les deux routes peuvent satisfaire le même contrat applicatif. Normalisez les champs de requête et de réponse, testez la sortie structurée ou le comportement des outils sur les deux modèles, et vérifiez toute capacité requise en images, documents, contexte ou raisonnement avant d’activer la route.
Le repli doit aussi respecter les effets de bord. Si la première route a déjà déclenché un outil, écrit des données, ou streamé une réponse partielle, répéter aveuglément la requête entière peut dupliquer des actions ou perturber l’utilisateur. Reprenez depuis un point de contrôle ou retournez un échec contrôlé à la place.
Contrôles de production qui maintiennent les réessais bornés
- Définissez un budget de latence total unique. Comptez chaque réessai et repli dans le même délai.
- Limitez les réessais. Utilisez un backoff avec gigue et arrêtez après une petite limite configurée.
- Contrôlez la concurrence. Réduisez les rafales avant que les requêtes ne quittent l’application.
- Ajoutez un disjoncteur. Arrêtez temporairement d’appeler une route qui échoue de façon répétée.
- Journalisez les décisions. Capturez le statut, le code d’erreur, l’ID de requête, le modèle, la tentative, le délai et la raison du repli sans stocker de secrets.
- Suivez le taux de repli. Une augmentation soutenue est un signal opérationnel, pas une métrique de succès normale.
Foire aux questions
Un 401 doit-il jamais déclencher un repli de modèle ?
Non. Corrigez ou rechargez la clé API. Un autre modèle appelé avec les mêmes identifiants invalides échouera pour la même raison.
Un 404 doit-il déclencher un repli ?
Pas par défaut. Corrigez d’abord la base URL ou l’endpoint. Seul un signal d’indisponibilité de modèle, vérifié séparément, doit entrer dans le classificateur de repli.
Combien de fois faut-il réessayer un 429 ?
Utilisez une petite limite définie par l’application qui s’adapte au budget de latence côté utilisateur. Faites du backoff avec gigue et réduisez la concurrence ; n’effectuez pas de réessais immédiats ou indéfinis.
Toutes les erreurs 5xx sont-elles réessayables ?
Non. Les réponses 500, 503, 504 et 524 temporaires sont des candidates au réessai, mais un 500 avec invalid_request doit échouer strictement tant que la charge utile n’est pas corrigée.
Claude et GPT peuvent-ils utiliser la même requête inchangée ?
Uniquement pour les champs partagés que votre application a testés. Les paramètres spécifiques au fournisseur, les formats d’outils, les sorties structurées et les entrées multimodales peuvent nécessiter des adaptateurs. Un simple changement d’ID de modèle ne prouve pas la compatibilité.
Où est l’implémentation complète du repli ?
Consultez Comment créer des stratégies robustes de repli de modèle pour LLM pour l’architecture globale, et le guide de repli de modèle CometAPI pour les détails d’implémentation.
Faites du classificateur d’erreurs le gardien
Le repli automatique est utile lorsqu’il est étroit et observable. Laissez les erreurs d’authentification, de chemin et de requête malformée échouer bruyamment. Réessayez les limites de débit et les pannes serveur temporaires avec backoff, puis passez à une route compatible seulement après que le budget de réessais est consommé. Cette politique fait du repli un contrôle de fiabilité plutôt qu’un moyen de dissimuler des bugs de configuration.