त्रुटियाँ और सीमाएँ

/v1/* पर GetVibe द्वारा produce किए गए errors का एक JSON envelope होता है जिसमें error.message, error.type और error.code होते हैं। message text या third-party service headers को contract की तरह न मानें।

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

हर अनुरोध त्रुटि में नीचे दी गई तालिका से एक स्थिर error.code, संबंधित फ़ील्ड वाला error.param (जब मॉडल ने किसी फ़ील्ड का नाम नहीं दिया हो तो null), और error.message के अंत में संबंधित पंक्ति का एक लिंक होता है — Codex और अन्य CLI केवल संदेश दिखाते हैं, इसलिए लिंक भी वहीं दिखाई देता है।

एक slow stream (stream: true) को 5 सेकंड की silence के बाद 200 और : pv-keepalive comments मिलते हैं ताकि connection मृत न लगे; किसी लंबी non-stream request को उसके पहले token के बाद 200 और whitespace मिलते हैं। उसके बाद status बदल नहीं सकता और error body में आती है। अगर आपका client किसी HTTP error पर दूसरे supplier पर fall back करता है, तो x-pv-honest-errors: 1 भेजें (या support से इसे account के लिए enable करने को कहें): तब न कोई keepalive होता है और न पहले response byte से पहले कोई early 200, और हर failure एक सामान्य HTTP status होती है जिसमें JSON body होती है। कीमत पहले token तक silent socket की है; आपका header timeout उसे cover करना चाहिए।

response शुरू होने के बाद आने वाली error एक terminal event होती है: chat के लिए event: error with {"error":{message,type,code,status},"choices":[{"finish_reason":"error"}]} followed by data: [DONE]; /v1/responses के लिए event: response.failed जिसमें वही error होता है; /v1/messages के लिए Anthropic का event: error। code machine cause है और status वह HTTP status है जो response शुरू होने से पहले error का होता।

दोनों सीमाएँ खाते की वर्तमान शेष राशि पर निर्भर करती हैं और उसकी सभी API कुंजियों पर संयुक्त रूप से लागू होती हैं। श्रेणी की गणना अपने-आप दोबारा होती है: राशि जोड़ने पर सीमा बढ़ जाती है; शेष राशि किसी निर्धारित स्तर से नीचे जाने पर श्रेणी घट जाती है। प्रति मिनट टोकन (TPM) की कोई सीमा नहीं है।

retryable response के लिए पहले Retry-After इस्तेमाल करें, अगर मौजूद हो। header के बिना, किसी भी 429 या 503 को अपने आप retryable न मानें: HTTP status और public error.type जाँचें, non-retryable कारण ठीक करें और केवल transient error के लिए bounded backoff इस्तेमाल करें।

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