Pour les agents IA : guide de configuration étape par étape — /docs/agents.md, index de la documentation — /llms.txt.

Erreurs et limites

Limites de requêtes, délais d'attente et codes d'erreur de la passerelle. Pour chaque réponse, nous indiquons quand elle survient et quoi faire : relancer la requête ou la corriger.

Les chiffres proviennent du champ limits de la réponse GET /v1/capabilities : les valeurs y sont toujours à jour.

Longueur de réponse par modèle#

Sans max_tokens, la passerelle applique une valeur par défaut : sans streaming — plus courte, pour que la réponse tienne dans les timeouts ; en streaming — le plafond du modèle. max_completion_tokens — même champ.

Le corps de l'erreur est un objet error avec les champs message, type, code, param ; certains champs ne sont pas présents sur toutes les erreurs. Fiez-vous au statut et au type, vérifiez via code : le texte message peut changer. Le format Anthropic est décrit dans la section Format des erreurs Anthropic.

{
  "error": {
    "message": "Model is currently overloaded in the Gonka network",
    "type": "rate_limit_exceeded",
    "code": "upstream_rate_limited"
  }
}

Tant que le flux n'est pas ouvert, le refus arrive avec un code de réponse classique — comme sans streaming. Une fois ouvert, le statut est déjà 200, et l'erreur arrive ainsi :

• Chat Completions — chunk joingonka-error avec le champ error, puis coupure sans [DONE].
• Sans streaming après une réponse précoce — statut 200 et corps avec le champ error.
• Anthropic Messages — événement event: error, puis le flux se ferme.
• OpenAI Responses — événement response.failed, la cause est dans response.error.code.
• Legacy Completions — data: {"error": …}, puis [DONE].

data: {"id":"joingonka-error","object":"chat.completion.chunk","model":"MiniMaxAI/MiniMax-M2.7","choices":[],"error":{"message":"Gonka network error","type":"api_error"}}

• POST /v1/messages répond avec l'enveloppe Anthropic : {"type": "error", "error": {"type", "message"}}.
• Les refus de la passerelle conservent le type du tableau ci-dessus (insufficient_funds, model_unavailable et autres) ; le champ code n'existe pas dans cette enveloppe — la cause est dans le texte.
• Erreurs de forme de la requête — invalid_request_error : messages ou max_tokens absents, appel d'outil sans nom, modèle inconnu.
• Chemin inconnu — not_found_error, corps trop volumineux — request_too_large.

event: error
data: {"type":"error","error":{"type":"timeout","message":"Upstream timeout"}}

• Après la pause indiquée dans Retry-After : 429
• Avec une pause croissante — 1, 2, 4 s et ainsi de suite : 500, 502, 503 service_unavailable, 504
• Avec un autre modèle : 503 model_unavailable
• Ne pas réessayer sans modifications — corrigez la requête, la clé ou le solde : 400, 401, 402, 403, 404, 413, 415, 501

Chaque nouvelle tentative après 504 entraîne un nouveau débit de l'estimation d'entrée ; pour les réponses longues, activez stream: true.

Si l'erreur persiste, écrivez au support en joignant x-request-id des en-têtes de réponse.