Erreur Claude 529 overloaded_error — cause et stratégie de nouvelle tentative

529 est la seule erreur Claude que votre code n’a pas provoquée : la saturation vient d’Anthropic. Vous ne pouvez pas la corriger — seulement l’absorber avec élégance. Cela signifie effectuer des tentatives patientes avec backoff, prévoir un modèle de secours pour les routes sensibles à la latence et, surtout, éviter les rafales de tentatives immédiates qui amplifient l’incident.

L’erreur

respuesta (HTTP 529)

{
  "type": "error",
  "error": { "type": "overloaded_error",
             "message": "Overloaded" }
}

Causes et solutions en bref

Cause	Solution
Saturation du côté du fournisseur (jours de lancement, incidents régionaux). Elle touche tous les clients en même temps.	Backoff avec jitter ; consultez la page d’état d’Anthropic au lieu de redéployer votre application.
Votre propre pic de charge s’ajoute à une capacité déjà sous tension.	Répartissez les tâches par lots ; dix minutes de retard suffisent généralement à laisser la situation se résorber.
Confusion avec 429 : dans les journaux, une limite de débit y ressemble, mais la cause est totalement différente.	429 signifie que vous avez dépassé vos limites (le serveur fonctionne normalement) ; 529 signifie que le serveur est saturé (votre quota est correct). Seul 429 fournit un indice Retry-After.
Aucun secours n’est défini, donc un problème du fournisseur atteint directement l’utilisateur final.	Définissez une chaîne de secours — au sein de la même famille (Sonnet → Haiku), le comportement reste similaire ; entre fournisseurs (Claude → GPT), vous survivez à un incident complet.

Réessayer sans amplifier l’incident

Traitez 529 comme 429 sans Retry-After : backoff exponentiel à partir d’environ 2 secondes, avec jitter, plafonné à 30–60 secondes, abandon après environ cinq tentatives et mise en file du travail. Le jitter est essentiel : sans lui, tous les clients reviennent en même temps et prolongent précisément la saturation dont ils tentent de sortir.

Basculer plutôt que tomber en panne

Pour les routes sensibles à la latence, définissez une chaîne de secours. Dans un endpoint compatible avec OpenAI, il suffit de modifier une chaîne de texte — sans second SDK ni second compte :

failover.py

PREFERRED = ["claude-sonnet-5", "claude-haiku-4-5", "gpt-5-6-terra"]

def complete(messages):
    last = None
    for model in PREFERRED:
        try:
            return client.chat.completions.create(
                model=model, messages=messages, max_tokens=800)
        except APIStatusError as e:
            if e.status_code not in (429, 500, 529):
                raise
            last = e          # saturado — probar el siguiente nivel
    raise last

Et seulement ensuite examiner votre code

Si les 529 apparaissent uniquement pour un type de requête tandis que les autres appels passent au même moment, il ne s’agit pas d’un incident général : vérifiez si cette route envoie des prompts inhabituellement volumineux ou se déclenche dans une boucle fermée. Si, au contraire, tous les appels sont affectés simultanément puis reviennent à la normale d’eux-mêmes, il s’agissait d’un problème de capacité — le travail relève alors des tentatives et du secours, pas d’une refactorisation.

Si vous appelez via Kunavo

Kunavo achemine Claude par plusieurs voies d’origine, et son catalogue multimodèle transforme le basculement entre fournisseurs en un changement de nom de modèle avec la même clé et le même portefeuille — le principe ci-dessus ne nécessite pas de second compte. Les erreurs 529 qui vous parviennent malgré tout ne sont jamais facturées. Capacité et prix sont deux questions distinctes ; pour la seconde, les tarifs par modèle sont disponibles dans les tarifs de Claude.

Questions fréquentes

Un 529 est-il de ma faute ?

Non. Il s’agit d’un problème de capacité côté fournisseur. Vos seules responsabilités sont de ne pas amplifier l’incident (backoff, jitter) et de prévoir une solution de secours si l’incident dure plus longtemps que votre budget de latence.

529 contre 429 : quelle est la différence ?

429 signifie que vous avez dépassé vos limites ; le serveur fonctionne normalement. 529 signifie que le serveur lui-même est saturé ; votre quota est correct. Les deux erreurs peuvent faire l’objet d’une nouvelle tentative ; seul 429 fournit un indice Retry-After.

Combien de temps dure normalement un épisode de 529 ?

Ce n’est ni prévisible ni garanti — c’est pourquoi la bonne réponse est un backoff plafonné associé à une file d’attente, et non une durée d’attente gravée dans le code. Si votre route a un budget de latence, le secours prend le relais plutôt que l’attente.

Les appels qui se terminent par une erreur 529 sont-ils facturés ?

Avec Kunavo, non : une requête qui se termine par une erreur n’est pas facturée. En contrat direct, cela dépend des règles de facturation du fournisseur concerné.

Guides associés

La sémantique détaillée des erreurs est disponible dans référence des erreurs ; obtenir une clé prend une minute via inscription et la guide d’authentification.