Erreurs et limites

Les erreurs produites par GetVibe sur /v1/* contiennent une enveloppe JSON avec error.message, error.type et error.code. Ne vous fiez pas au texte du message ni aux en-têtes des services tiers comme s’il s’agissait d’un contrat.

{
  "error": {
    "message": "insufficient balance",
    "type": "insufficient_quota",
    "code": 402,
    "request_id": "8d4b6b3a-..."
  }
}

Chaque erreur de requête contient un error.code stable provenant du tableau ci-dessous, un error.param indiquant le champ concerné (null lorsque le modèle n’en a pas indiqué), ainsi qu’un lien vers la ligne correspondante à la fin de error.message — Codex et les autres CLI n’affichent que le message ; le lien y est donc inclus.

Un flux lent (stream: true) reçoit 200 et : pv-keepalive commentaires après 5 secondes de silence afin que la connexion ne semble pas interrompue ; une longue requête sans flux reçoit 200 et des espaces après son premier jeton. À partir de là, le statut ne peut plus changer et une erreur arrive dans le corps. Si votre client bascule vers un autre fournisseur en cas d’erreur HTTP, envoyez x-pv-honest-errors: 1 (ou demandez au support de l’activer pour le compte) : il n’y a alors aucun keepalive ni aucun 200 anticipé avant le premier octet de la réponse, et chaque échec correspond à un statut HTTP ordinaire avec un corps JSON. Le coût est une socket silencieuse jusqu’au premier jeton ; votre délai d’expiration des en-têtes doit le couvrir.

Une erreur survenant après le début de la réponse constitue un événement terminal unique : pour le chat event: error avec {"error":{message,type,code,status},"choices":[{"finish_reason":"error"}]}, suivi de data: [DONE] ; pour /v1/responses event: response.failed contenant le même error ; pour /v1/messages, le event: error d’Anthropic. code indique la cause technique et status correspond au statut HTTP qu’aurait eu l’erreur avant le début de la réponse.

Les deux limites dépendent du solde actuel du compte et s’appliquent à l’ensemble de ses clés API. Le palier est recalculé automatiquement : rechargez votre compte et la limite augmente ; si le solde passe sous un seuil, le palier diminue. Il n’y a pas de limite de tokens par minute (TPM).

Pour une réponse pouvant faire l'objet d'une nouvelle tentative, utilisez d'abord Retry-After, s'il est présent. Sans cet en-tête, ne considérez aucun 429 ou 503 comme automatiquement réessayable : vérifiez le statut HTTP et le error.type public, corrigez la cause non réessayable et utilisez un backoff limité uniquement en cas d'erreur transitoire.

import time, requests

def call_with_retry(url, headers, payload, max_retries=5):
    for attempt in range(max_retries):
        r = requests.post(url, headers=headers, json=payload)
        if r.status_code == 429:
            # honor Retry-After, otherwise exponential backoff
            wait = int(r.headers.get("Retry-After", 2 ** attempt))
            time.sleep(wait)
            continue
        return r
    return r