Errors and limits

Errors produced by GetVibe on /v1/* have a JSON envelope with error.message, error.type and error.code. Do not rely on the message text or third-party service headers as a contract.

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

Every request error carries a stable error.code from the table below, error.param with the field it concerns (null when the model did not name one), and a link to the matching row at the end of error.message — Codex and other CLIs show only the message, so the link travels there.

A slow stream (stream: true) gets 200 and : pv-keepalive comments after 5 seconds of silence so the connection does not look dead; a long non-stream request gets 200 and whitespace after its first token. From then on the status cannot change and an error arrives in the body. If your client falls back to another supplier on an HTTP error, send x-pv-honest-errors: 1 (or ask support to enable it for the account): there is then no keepalive and no early 200 before the first response byte, and every failure is an ordinary HTTP status with a JSON body. The cost is a silent socket until the first token; your header timeout must cover it.

An error after the response has started is one terminal event: for chat event: error with {"error":{message,type,code,status},"choices":[{"finish_reason":"error"}]} followed by data: [DONE]; for /v1/responses event: response.failed carrying the same error; for /v1/messages Anthropic's event: error. code is the machine cause and status is the HTTP status the error would have had before the response started.

Both limits depend on the account's current balance and apply to all of its API keys together. The tier is recalculated automatically: top up and the limit rises; drop below a threshold and the tier goes down. There is no tokens-per-minute (TPM) limit.

For a retryable response first use Retry-After, if present. Without the header, do not treat any 429 or 503 as automatically retryable: check the HTTP status and the public error.type, fix the non-retryable cause and use bounded backoff only for a transient error.

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