Errores y límites

Los errores producidos por GetVibe en /v1/* tienen una envoltura JSON con error.message, error.type y error.code. No dependas del texto del mensaje ni de los encabezados del servicio de terceros como contrato.

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

Cada error de solicitud incluye un error.code estable de la tabla siguiente, error.param con el campo al que corresponde (null cuando el modelo no indicó ninguno) y un enlace a la fila correspondiente al final de error.message; Codex y otras CLI solo muestran el mensaje, por lo que el enlace también aparece allí.

Una transmisión lenta (stream: true) recibe 200 y : pv-keepalive comentarios después de 5 segundos de silencio para que la conexión no parezca inactiva; una solicitud larga sin transmisión recibe 200 y espacios en blanco después de su primer token. A partir de ese momento, el estado no puede cambiar y llega un error en el cuerpo. Si tu cliente recurre a otro proveedor ante un error HTTP, envía x-pv-honest-errors: 1 (o solicita al soporte que lo habilite para la cuenta): en ese caso no hay keepalive ni un 200 anticipado antes del primer byte de respuesta, y cada fallo es un estado HTTP normal con un cuerpo JSON. El costo es un socket silencioso hasta el primer token; el tiempo de espera de los encabezados debe cubrirlo.

Un error después de que comenzó la respuesta es un evento terminal: para chat event: error con {"error":{message,type,code,status},"choices":[{"finish_reason":"error"}]} seguido de data: [DONE]; para /v1/responses event: response.failed que lleva el mismo error; para /v1/messages, el event: error de Anthropic. code es la causa para la máquina y status es el estado HTTP que habría tenido el error antes de que comenzara la respuesta.

Ambos límites dependen del saldo actual de la cuenta y se aplican al conjunto de todas sus claves de API. El nivel se recalcula automáticamente: recarga el saldo y el límite sube; si el saldo cae por debajo de un umbral, el nivel baja. No hay límite de tokens por minuto (TPM).

Para una respuesta que se puede reintentar, usa primero Retry-After, si está presente. Sin el encabezado, no trates ningún 429 o 503 como reintentable automáticamente: comprueba el estado HTTP y el error.type público, corrige la causa no reintentable y usa un retroceso limitado solo para un error transitorio.

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