Erros e limites

Os erros produzidos pelo GetVibe em /v1/* têm um envelope JSON com error.message, error.type e error.code. Não dependa do texto da mensagem nem dos headers de serviços de terceiros como contrato.

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

Todo erro de requisição inclui um error.code estável da tabela abaixo, error.param com o campo ao qual se refere (null quando o modelo não especifica um) e um link para a linha correspondente no final de error.message — o Codex e outras CLIs mostram apenas a mensagem, por isso o link é incluído nela.

Uma transmissão lenta (stream: true) recebe 200 e : pv-keepalive comentários após 5 segundos de silêncio, para que a conexão não pareça inativa; uma solicitação longa sem transmissão recebe 200 e espaços em branco após o primeiro token. A partir desse momento, o status não pode mudar e um erro chega no corpo. Se o cliente alternar para outro fornecedor após um erro HTTP, envie x-pv-honest-errors: 1 (ou peça ao suporte para ativá-lo para a conta): nesse caso, não haverá keepalive nem um 200 antecipado antes do primeiro byte da resposta, e toda falha será um status HTTP comum com um corpo JSON. O custo é um socket silencioso até o primeiro token; o tempo limite do cabeçalho precisa cobrir esse período.

Um erro após o início da resposta é um único evento terminal: para chat event: error com {"error":{message,type,code,status},"choices":[{"finish_reason":"error"}]} seguido por data: [DONE]; para /v1/responses event: response.failed contendo o mesmo error; para /v1/messages, o event: error da Anthropic. code é a causa identificável pela máquina e status é o status HTTP que o erro teria antes do início da resposta.

Ambos os limites dependem do saldo atual da conta e se aplicam a todas as suas chaves de API em conjunto. A faixa é recalculada automaticamente: adicione saldo e o limite aumenta; se o saldo cair abaixo de um limiar, a faixa diminui. Não há limite de tokens por minuto (TPM).

Para uma resposta que pode ser repetida, use primeiro Retry-After, se presente. Sem o cabeçalho, não trate nenhum 429 ou 503 como repetível automaticamente: verifique o status HTTP e o error.type público, corrija a causa que não pode ser repetida e use backoff limitado somente para um erro transitório.

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