Error dan batas

Error yang dihasilkan GetVibe pada /v1/* memiliki envelope JSON dengan error.message, error.type dan error.code. Jangan mengandalkan teks pesan atau header layanan pihak ketiga sebagai kontrak.

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

Setiap error permintaan menyertakan error.code yang tetap dari tabel di bawah, error.param berisi kolom yang terkait (null jika model tidak menyebutkannya), dan tautan ke baris yang sesuai di akhir error.message — Codex dan CLI lainnya hanya menampilkan pesan, jadi tautan disertakan di sana.

Stream yang lambat (stream: true) menerima komentar 200 dan : pv-keepalive setelah 5 detik tanpa aktivitas agar koneksi tidak terlihat mati; permintaan non-stream yang panjang menerima 200 dan spasi setelah token pertamanya. Setelah itu status tidak dapat berubah dan error datang di body. Jika klien Anda beralih ke supplier lain saat terjadi error HTTP, kirim x-pv-honest-errors: 1 (atau minta dukungan mengaktifkannya untuk akun): dengan begitu tidak ada keepalive dan tidak ada 200 dini sebelum byte respons pertama, dan setiap kegagalan menjadi status HTTP biasa dengan body JSON. Konsekuensinya adalah socket yang senyap hingga token pertama; timeout header Anda harus mencakupnya.

Error setelah respons dimulai merupakan satu peristiwa terminal: untuk chat event: error dengan {"error":{message,type,code,status},"choices":[{"finish_reason":"error"}]} diikuti oleh data: [DONE]; untuk /v1/responses event: response.failed yang membawa error yang sama; untuk /v1/messages event: error milik Anthropic. code adalah penyebab mesin dan status adalah status HTTP yang seharusnya dimiliki error tersebut sebelum respons dimulai.

Kedua batas bergantung pada saldo akun saat ini dan berlaku untuk semua API key akun tersebut secara bersamaan. Tier dihitung ulang secara otomatis: isi saldo dan batasnya naik; turun di bawah ambang batas dan tier akan turun. Tidak ada batas tokens-per-minute (TPM).

Untuk respons yang dapat dicoba ulang, pertama gunakan Retry-After jika ada. Tanpa header tersebut, jangan anggap 429 atau 503 apa pun otomatis dapat dicoba ulang: periksa status HTTP dan error.type publik, perbaiki penyebab yang tidak dapat dicoba ulang, dan gunakan backoff terbatas hanya untuk error sementara.

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