AI API سے 429 Too Many Requests: بیک آف کے ساتھ ریٹریز

AI API کی طرف سے 429 Too Many Requests کا مطلب ہے کہ درخواست مسترد کر دی گئی کیونکہ آپ نے بہت زیادہ اور بہت تیزی سے بھیجا، یا آپ کے اکاؤنٹ کی حد کو چھو لیا۔ اس کا حل یہ ہے کہ انتظار کریں اور exponential backoff اور jitter کے ساتھ دوبارہ کوشش کریں، جب جواب میں Retry-After ہیڈر موجود ہو تو اسے استعمال کریں، اور اپنے ایجنٹ کے متوازی بھیجے جانے والے درخواستوں کی تعداد کو محدود کریں۔ کسی 429 کو دوبارہ کوشش نہ کریں جو دراصل خرچ یا بیلنس کی حد ہے: انتظار اسے ٹھیک نہیں کرے گا۔

یہ گائیڈ OpenAI اور Anthropic کے سرکاری ریٹ-لمٹ گائیڈز پر مبنی ہے، دونوں 22 اکتوبر 2026 کو چیک کیے گئے۔ دونوں صفحات پر آخری تازہ کاری کی تاریخ نہیں دکھائی گئی۔

429 کا مطلب کیا ہے#

OpenAI 429 کو اس درخواست کے طور پر بیان کرتا ہے جو ریٹ لمٹ سے تجاوز کرنے کی وجہ سے مسترد ہوئی (rate_limit_error، جب ٹریفک بہت تیزی سے بڑھے تو کوڈ slow_down کے ساتھ)، یا اس لیے کہ سخت خرچ کی حد تک پہنچ گئی۔ Anthropic بھی 429 کے لیے rate_limit_error استعمال کرتا ہے۔ خرچ کی حد والے 429 میں retry-after ہیڈر نہیں ہوتا اور رسائی دوبارہ شروع ہونے تک ناکام ہوتا رہتا ہے۔

اس کے ساتھ دو قریبی چیزیں آسانی سے الجھ جاتی ہیں۔ OpenAI کا 503 server_is_overloaded اور Anthropic کا 529 overloaded_error اوورلوڈ حالات ہیں، آپ کی ریٹ لمٹ نہیں۔ انہیں عام طور پر اسی ریٹری لوپ سے سنبھالا جاتا ہے، لیکن وہ وجہ کے بارے میں کچھ مختلف بتاتے ہیں۔

تو تین صورتیں ہیں، اور ہر ایک کو مختلف ردعمل کی ضرورت ہے:

اگر آپ کا بیلنس ختم ہو گیا ہے، تو "not enough tokens" خرابی پڑھیں۔ نیٹ ورک کی سطح کی ناکامیوں جیسے ٹائم آؤٹ اور مسترد کنکشنز کے لیے، عام کنکشن خرابیاں دیکھیں۔

تاخیر کا اندازہ لگانے سے پہلے ہیڈرز پڑھیں#

OpenAI ریٹ-لمٹڈ جوابات پر یہ ہیڈرز دستاویز کرتا ہے: Retry-After، اور x-ratelimit-limit-requests، x-ratelimit-remaining-requests، x-ratelimit-reset-requests -tokens اقسام کے ساتھ۔ دیگر APIs ان کا ایک ذیلی مجموعہ یا کوئی بھی نہیں بھیج سکتے ہیں، لہذا کلائنٹ کو اس طرح لکھیں کہ جب Retry-After موجود ہو تو استعمال کرے اور جب نہ ہو تو اپنے شیڈول پر واپس جائے۔

OpenAI کی ریٹریز پر رہنمائی، مختصراً:

• Retry-After کو کم از کم انتظار سمجھیں اور اس کے اوپر ایک چھوٹی بے ترتیب تاخیر شامل کریں۔
• اس کے بغیر، jitter کے ساتھ exponential backoff استعمال کریں۔
• کوششوں کی تعداد اور کل ریٹری وقت دونوں کو محدود کریں۔
• SDK کی ریٹریز کے اوپر اپنی ریٹریز نہ رکھیں۔
• کوٹہ یا بلنگ کی خرابیوں پر دوبارہ کوشش نہ کریں۔
• ناکام درخواستیں اب بھی فی منٹ کی حد میں شمار ہوتی ہیں، لہذا جارحانہ لوپ حالات کو مزید خراب کرتا ہے۔
• اسٹریمنگ کے لیے، کسی درخواست سے آؤٹ پٹ استعمال کرنے کے بعد اسے دوبارہ نہ چلائیں۔

Python: jitter کے ساتھ بیک آف#

سرکاری openai پیکیج کسی بھی OpenAI-مطابق اینڈ پوائنٹ کے ساتھ کام کرتا ہے۔ SDK کی اپنی ریٹریز بند کریں (max_retries=0) تاکہ وہ آپ کی ریٹریز کے ساتھ ضرب نہ ہوں۔ ماڈل کی id CheapTokens docs سے آتی ہے؛ ids فراہم کنندگان کے درمیان مختلف ہوتی ہیں۔

import os
import random
import time

from openai import OpenAI, APIStatusError

client = OpenAI(
    base_url="https://api.cheaptokens.dev/v1",
    api_key=os.environ["CHEAPTOKENS_API_KEY"],
    max_retries=0,  # we retry ourselves
)

RETRYABLE = {429, 500, 502, 503, 504}


def chat_with_retry(model, messages, max_attempts=5, max_total=60.0):
    started = time.monotonic()
    for attempt in range(max_attempts):
        try:
            return client.chat.completions.create(model=model, messages=messages)
        except APIStatusError as err:
            last = attempt == max_attempts - 1
            if err.status_code not in RETRYABLE or last:
                raise
            header = err.response.headers.get("retry-after")
            if header and header.replace(".", "", 1).isdigit():
                delay = float(header) + random.uniform(0, 1)  # minimum wait + jitter
            else:
                delay = random.uniform(0, min(30.0, 2.0 ** attempt))  # full jitter
            if time.monotonic() - started + delay > max_total:
                raise
            time.sleep(delay)

ہیڈر کے بغیر تاخیر کی بالائی حد 1، 2، 4، 8 سیکنڈ بڑھتی ہے (30 پر محدود)، اور random.uniform اس سے کم ایک بے ترتیب قدر چنتا ہے، تاکہ بہت سے ورکرز ایک ہی وقت میں نہ جاگیں۔ Retry-After ایک HTTP تاریخ بھی ہو سکتی ہے؛ اوپر کا کوڈ عددی شکل کو سنبھالتا ہے اور بصورت دیگر بیک آف پر واپس جاتا ہے۔

JavaScript: وہی لوپ#

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.cheaptokens.dev/v1",
  apiKey: process.env.CHEAPTOKENS_API_KEY,
  maxRetries: 0, // we retry ourselves
});

const RETRYABLE = new Set([429, 500, 502, 503, 504]);
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

export async function chatWithRetry(model, messages, maxAttempts = 5, maxTotalMs = 60000) {
  const started = Date.now();
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await client.chat.completions.create({ model, messages });
    } catch (err) {
      const last = attempt === maxAttempts - 1;
      if (!RETRYABLE.has(err.status) || last) throw err;
      const header = Number(err.headers?.get?.("retry-after"));
      const delayMs = Number.isFinite(header) && header > 0
        ? header * 1000 + Math.random() * 1000 // minimum wait + jitter
        : Math.random() * Math.min(30000, 2 ** attempt * 1000); // full jitter
      if (Date.now() - started + delayMs > maxTotalMs) throw err;
      await sleep(delayMs);
    }
  }
}

جب یہ کام کرتا ہے، ریٹ-لمٹڈ کال بس زیادہ وقت لیتی ہے اور پھر ایک عام تکمیل واپس کرتی ہے۔ جب آخری کوشش کے بعد بھی ناکام ہو جائے، تو اصل خرابی اٹھائی جاتی ہے، تاکہ آپ کا کوڈ اسے لاگ کر سکے یا جاب کو بعد کے لیے قطار میں لگا سکے۔

ایجنٹس کو 429 کیسے سنبھالنا چاہیے#

ایک ایجنٹ لوپ بہت سی مختصر کالیں بھیجتا ہے، اور کئی ایجنٹس یا ٹول کالیں ایک ساتھ چل سکتی ہیں۔ صرف دوبارہ کوشش کرنا کافی نہیں؛ درخواست کی شرح کو ذریعہ پر کم کریں:

1. Concurrency کو محدود کریں۔ 3–5 متوازی کالوں کا سیمفور ایک معقول آغاز ہے؛ اسے صرف اس وقت بڑھائیں جب خرابیاں کم رہیں۔
2. ایک ہی محدود کنندہ شیئر کریں۔ اگر کئی ورکرز ایک ہی کلید استعمال کرتے ہیں، تو وہ ایک ہی حدود شیئر کرتے ہیں، لہذا فی ورکر ایک ریٹری لوپ کافی نہیں: عمل کے لیے ایک قطار یا ایک سیمفور استعمال کریں۔
3. عالمی طور پر بیک آف کریں۔ جب ایک کال کو تاخیر کے ساتھ 429 ملے، تو صرف ناکام کال کے بجائے پورے پول کو اس وقت کے لیے روکیں۔
4. درخواستیں چھوٹی رکھیں۔ فی درخواست کم ٹوکنز کا مطلب فی منٹ ٹوکن کی حدود پر کم دباؤ: تاریخ اور ٹول آؤٹ پٹ کو تراشیں۔ ٹوکنز کہاں جاتے ہیں اس کے لیے AI ایجنٹ کی لاگت کا اندازہ کیسے لگائیں دیکھیں۔
5. غیر ریٹریبل خرابیوں پر رکیں۔ 401، 400، یا بیلنس کی خرابی خود ٹھیک نہیں ہوگی؛ تیزی سے ناکام ہوں اور رپورٹ کریں۔

import asyncio

limit = asyncio.Semaphore(4)  # at most 4 requests in flight


async def run(job):
    async with limit:
        return await call_model(job)  # your async call with the retry loop above

CheapTokens پر ایجنٹ لوپس چلائیں#

بہت سی مختصر کالوں والے ایجنٹ لوپس کے لیے، CheapTokens MiniMax-M2.7 پیش کرتا ہے: دن کے کسی بھی وقت ایک قیمت، 180K سیاق و سباق، فی جواب 8,192 ٹوکنز تک، اور تمام ماڈلز کے لیے ایک بیلنس۔ آؤٹ پٹ کی لاگت $0.15 فی 1M ٹوکنز ہے، اور مجموعی طور پر، ان پٹ اور آؤٹ پٹ کو ملا کر، یہ OpenRouter سے سستا ہے۔ یہ OpenAI-مطابق اینڈ پوائنٹ https://api.cheaptokens.dev/v1 کے ذریعے کام کرتا ہے۔ اوپر کا کوڈ پہلے ہی اس اینڈ پوائنٹ کی طرف اشارہ کرتا ہے؛ CheapTokens docs سے ماڈل id سیٹ کریں اور اسے چلائیں۔

500,000-ان پٹ، 100,000-آؤٹ پٹ ورک لوڈ کے لیے لائیو قیمتیں:

تمام قیمتیں، سیٹ اپ docs دیکھیں، اور اپنی پہلی درخواست بھیجنے کے لیے ایک کلید بنائیں۔

اگر پھر بھی ناکام ہو#

• پہلی ہی درخواست پر 429۔ جواب کے باڈی میں خرابی کی قسم اور پیغام پڑھیں: خرچ یا اکاؤنٹ-حد والا 429 ریٹری پر ناکام ہوتا رہتا ہے جب تک حد بڑھائی نہ جائے یا رسائی دوبارہ شروع نہ ہو، جبکہ ریٹ-لمٹ والا 429 وقفے کے بعد صاف ہو جاتا ہے۔
• لمبے لوپ کے ساتھ 429 آتا رہتا ہے۔ آپ ریٹریز کو تہہ کر رہے ہوں گے: SDK ریٹریز ضرب آپ کی ریٹریز۔ SDK کو صفر پر سیٹ کریں، جیسا کہ مثالوں میں ہے۔
• بیچ کے آغاز میں خرابیاں جھرمٹ میں آتی ہیں۔ ایک ساتھ تمام ورکرز کو چلانے کے بجائے آہستہ آہستہ بڑھائیں؛ OpenAI بہت تیزی سے بڑھنے والے ٹریفک کے لیے slow_down رپورٹ کرتا ہے۔
• اسٹریمنگ کال درمیان میں ناکام ہو گئی۔ آؤٹ پٹ استعمال کرنے کے بعد اسے اندھا دھند دوبارہ نہ چلائیں؛ فیصلہ کریں کہ پورا جواب دوبارہ شروع کرنا ہے یا جو آپ کے پاس ہے اس سے جاری رکھنا ہے۔
• جواب میں Retry-After نہیں۔ کوڈ jitter کے ساتھ بیک آف پر واپس جاتا ہے، لہذا کوئی تبدیلی کی ضرورت نہیں۔