रेट लिमिट

Rate limits आपके बैलेंस और सेवा दोनों की सुरक्षा करती हैं। सीमाएँ हर API key के लिए प्रति मिनट requests (RPM) में गिनी जाती हैं, और keys पर दैनिक USD खर्च सीमा भी लगाई जा सकती है।

प्लान के अनुसार सीमाएँ

अपनी सीमा बढ़ाने के लिए प्राइसिंग पेज पर अपग्रेड करें।

प्रति-key सीमाएँ

API keys में key बनाते या बदलते समय आप ये सेट कर सकते हैं:

RPM window एक मिनट की होती है और हर key के लिए अलग गिनी जाती है, इसलिए अलग-अलग ऐप्स की अलग keys एक ही सीमा साझा नहीं करतीं, फिर भी हर key आपके प्लान की सीमा से बंधी रहती है।

दर सीमा हेडर

हर जनरेशन उत्तर (सफल या त्रुटि) बताता है कि आप कहां हैं, ताकि सीमा तक पहुंचने से पहले गति कम कर सकें:

ब्राउज़र क्लाइंट भी इन्हें पढ़ सकते हैं (ये Access-Control-Expose-Headers में हैं)।

अचानक भीड़ और समानांतर अनुरोध

सीमा से ऊपर के अनुरोध तुरंत अस्वीकार नहीं होते: वे कतार में इंतज़ार करते हैं और एक मिनट की विंडो खाली होते ही शुरू हो जाते हैं। हर अकाउंट के लिए एक साथ 10 अनुरोध तक चलते हैं, बाकी किसी एक के पूरा होने तक इंतज़ार करते हैं। अनुरोध शुरू होने से पहले उसकी अनुमानित अधिकतम लागत, चल रहे अनुरोधों की लागत के साथ, आपके बैलेंस से आरक्षित की जाती है, इसलिए समानांतर अनुरोध आपके बैलेंस से ज़्यादा खर्च नहीं कर सकते। जो अनुरोध 60 सेकंड में शुरू नहीं हो पाता वह Retry-After के साथ 429 (rate_limited या concurrency_limit) लौटाता है; जिसकी लागत अब बैलेंस में नहीं समाती वह 402 insufficient_balance लौटाता है।

Idempotency-Key के साथ सुरक्षित पुनः प्रयास

नेटवर्क त्रुटि के बाद आपको शायद पता न हो कि अनुरोध पहुंचा या नहीं। Idempotency-Key हेडर भेजें (120 अक्षरों तक की अद्वितीय स्ट्रिंग, जैसे UUID) और उसी कुंजी से फिर प्रयास करें: अगर पहला अनुरोध मॉडल को भेजा जा चुका है तो पुनः प्रयास काम को दो बार चलाने और शुल्क लेने के बजाय 409 idempotency_conflict लौटाता है। अगर पहला अनुरोध मॉडल तक पहुंचने से पहले विफल हुआ, तो कुंजी मुक्त हो जाती है और पुनः प्रयास सामान्य रूप से चलता है। एक कुंजी प्रति खाता 24 घंटे में एक बार इस्तेमाल हो सकती है।

curl https://api14.com/api/v1/images/generations \
  -H "Authorization: Bearer $API14_KEY" \
  -H "Idempotency-Key: 6f1c2a3e-order-1842" \
  -H "Content-Type: application/json" \
  -d '{"model": "black-forest-labs/flux-3-image", "prompt": "a red bicycle"}'

जब आप सीमा तक पहुँच जाएँ

बहुत ज़्यादा requests

HTTP/1.1 429 Too Many Requests
Retry-After: 60

{
  "error": {
    "message": "Rate limit of 5 requests per minute exceeded.",
    "type": "rate_limit_error",
    "code": "rate_limited"
  }
}

Retry-After में दिए गए सेकंड तक रुकें, फिर दोबारा कोशिश करें। आधिकारिक OpenAI SDK 429 responses पर backoff के साथ अपने-आप दोबारा कोशिश करते हैं (डिफ़ॉल्ट रूप से दो बार; maxRetries / max_retries से कॉन्फ़िगर करें)।

दैनिक खर्च सीमा

{
  "error": {
    "message": "This API key reached its daily spend limit.",
    "type": "rate_limit_error",
    "code": "daily_limit_reached"
  }
}

अगले UTC दिन तक दोबारा कोशिश करने से कोई फ़ायदा नहीं। अगर यह अपेक्षित ट्रैफ़िक है, तो API keys में key की दैनिक सीमा बढ़ाएँ या हटा दें।

Upstream सीमाएँ

प्रोवाइडर्स की अपनी सीमाएँ होती हैं, जो :free मॉडल वैरिएंट के लिए ज़्यादा सख़्त होती हैं। जब कोई प्रोवाइडर किसी request को rate-limit करता है, तो उसका 429 आप तक पहुँचा दिया जाता है। लोड को कई प्रोवाइडर्स में बाँटने के लिए मॉडल fallbacks या provider routing इस्तेमाल करें।

कोड में सीमाएँ संभालना

• Retry-After का पालन करें और exponential backoff व jitter के साथ दोबारा कोशिश करें।
• rate_limited (बाद में दोबारा कोशिश करें) को daily_limit_reached और insufficient_balance (दोबारा कोशिश बेकार है) से अलग पहचानें।
• Background jobs को एक साथ चलाने के बजाय queue में डालें।
• लंबे responses stream करें: एक streamed request एक ही request गिनी जाती है।

import time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api14.com/api/v1", api_key="sk-api14-...", max_retries=0)

for attempt in range(5):
    try:
        r = client.chat.completions.create(model="openai/gpt-5-mini", messages=[{"role": "user", "content": "Hi"}])
        break
    except RateLimitError as e:
        if e.code == "daily_limit_reached":
            raise
        time.sleep(int(e.response.headers.get("retry-after", 2 ** attempt)))

हर status code के लिए त्रुटियाँ देखें।