Claude usage limits کا حل کیا ہے؟

Claude کی usage limits کیا ہیں؟

Claude کی usage limits دو الگ الگ سسٹمز پر مشتمل ہیں، اور پہلا کام یہ جاننا ہے کہ آپ کو کس سسٹم نے روکا ہے۔ Claude subscription (Pro, Max, Team, یا Enterprise) آپ کو ایک rolling usage allowance فراہم کرتی ہے جو تمام models اور Claude chat کے درمیان مشترک ہوتی ہے، اس لیے یہ آپ کو You've hit your session limit · resets 3:45pm جیسے پیغام کے ساتھ روک دیتی ہے۔ Claude API ایک الگ چیز کو ناپتی ہے: آپ کتنی تیزی سے requests اور tokens بھیجتے ہیں، جس کا حساب فی منٹ کیا جاتا ہے۔ یہ آپ کو rate_limit_error قسم کے HTTP 429 error اور ایک retry-after header کے ساتھ روکتی ہے جو بتاتا ہے کہ کتنے seconds انتظار کرنا ہے۔

ان دونوں کے حل ایک دوسرے سے بالکل مختلف ہیں۔ Subscription limit کا تعلق اس بات سے ہے کہ آپ نے ایک مخصوص وقت (window) میں کتنا استعمال کیا ہے، اس لیے آپ reset کا انتظار کریں یا مزید usage خریدیں۔ API rate limit کا تعلق آپ کی موجودہ رفتار سے ہے، اور جیسے ہی آپ اپنی رفتار کم کرتے ہیں، یہ چند seconds میں ختم ہو جاتی ہے۔

Plan allowances اور rate-limit tier numbers اکثر تبدیل ہوتے رہتے ہیں، اور غلط نمبر فراہم کرنا نہ ہونے سے زیادہ نقصان دہ ہے، اس لیے یہاں کوئی نمبر نہیں دیا گیا ہے۔ نیچے دیے گئے commands کے ذریعے اپنی limits خود چیک کریں۔

آپ کو کون سی حد (limit) کا سامنا ہے؟ درست پیغام پڑھیں

Claude Code پرنٹ کیے گئے متن میں سسٹم کا نام بتاتا ہے۔ کوئی بھی تبدیلی کرنے سے پہلے اپنے سسٹم کا मिलान کریں۔

• You've hit your session limit · resets 3:45pm ایک سبسکرپشن حد ہے۔ اس ونڈو کے لیے آپ کے پلان کا رولنگ الاؤنس ختم ہو چکا ہے۔
• You've hit your weekly limit · resets Mon 12:00am طویل مدت والی ونڈو کے لیے وہی سسٹم ہے۔
• You've hit your Opus limit · resets 3:45pm ایک سبسکرپشن حد ہے جو صرف Opus requests پر لاگو ہوتی ہے۔ یہ واحد صورت ہے جہاں ماڈل تبدیل کرنا مددگار ثابت ہوتا ہے۔
• API Error: Request rejected (429) · this may be a temporary capacity issue. If it persists, check https://status.claude.com. ایک API rate limit ہے۔ آپ اپنے API key، یا Amazon Bedrock یا Google Cloud پروجیکٹ کے لیے کنفیگر کی گئی حد تک پہنچ گئے ہیں۔
• API Error: Server is temporarily limiting requests (not your usage limit) ایک عارضی تھروٹل (throttle) ہے جس کا آپ کے پلان کوٹے سے کوئی تعلق نہیں ہے۔ Claude Code اس لائن کو دکھانے سے پہلے خودکار طور پر backoff کے ساتھ اسے دوبارہ کوشش (retry) کرتا ہے۔

Subscription limits: session, weekly, and the Opus window

Subscription plan میں استعمال کی ایک مقررہ حد (rolling usage allowance) شامل ہوتی ہے۔ جب یہ حد ختم ہو جاتی ہے، تو Claude Code مزید درخواستوں کو روک دیتا ہے جب تک کہ میسج میں بتایا گیا ری سیٹ کا وقت نہ آ جائے۔ اس حد کی دو خصوصیات زیادہ تر الجھن کا باعث بنتی ہیں۔

• یہ Claude chat کے ساتھ مشترک ہے۔ claude.ai پر کیا گیا کام اسی حد سے استعمال ہوتا ہے جو ٹرمینل میں ہوتا ہے، اس لیے چیٹ میں زیادہ استعمال آپ کے کوڈنگ کے وقت کو کم کر سکتا ہے۔
• یہ تمام models کے درمیان مشترک ہے۔ Session اور weekly limits میں ہر model کے لیے الگ بجٹ نہیں ہوتا، سوائے Opus limit کے۔

Claude for Teams اور Enterprise میں، یہ حد فی صارف (per-seat) ہوتی ہے جو کہ 5 گھنٹے کے rolling window اور ایک weekly window پر ری سیٹ ہوتی ہے۔ یہ Claude chat اور Cowork کے ساتھ مشترک ہے، اور یہ آپ کے seat tier (Standard یا Premium) کے مطابق ہوتی ہے۔ Pro اور Max میں، میسج میں ظاہر ہونے والا ری سیٹ کا وقت اور آپ کے اپنے /usage bars ہی درست معلومات ہیں، نہ کہ کسی بلاگ پوسٹ سے لی گئی کوئی رقم۔ اگر آپ ابھی تک کوئی tier منتخب نہیں کر رہے، تو آپ کو کون سا Claude plan چاہیے اس کا موازنہ کرتا ہے کہ ہر پلان میں کیا پابندیاں ہیں۔

/model کے ذریعے ماڈل تبدیل کرنے سے رسائی کیوں بحال نہیں ہوتی

یہ سب سے عام غلطی ہے، اور دستاویزات اس بارے میں واضح ہیں: تمام ماڈلز کے لیے session اور weekly limits مشترکہ ہوتی ہیں، اس لیے ماڈل تبدیل کرنے سے رسائی بحال نہیں ہوتی۔ جب آپ کا session window ختم ہو جائے تو چھوٹا ماڈل منتخب کرنے سے صرف جواب دینے والا ماڈل تبدیل ہوتا ہے۔ اس سے باقی بچ جانے والی allowance تبدیل نہیں ہوتی، کیونکہ allowance کبھی بھی کسی خاص ماڈل کے لیے مخصوص نہیں تھی، اس لیے تبدیلی سے کوئی حد آزاد نہیں ہوتی۔

اس کا استثنا Opus limit ہے، جو کہ حقیقتاً ماڈل کے لحاظ سے مخصوص حد ہے۔ اگر پیغام You've hit your Opus limit نظر آئے، تو /model درست حل ہے۔ کسی دوسرے ماڈل پر سوئچ کریں اور کام جاری رکھیں، کیونکہ صرف Opus requests بلاک کی گئی تھیں۔

حد (limit) کو بگ (bug) سمجھنا دوسری غلطی ہے۔ Reinstalling یا re-authenticating کرنے سے کچھ نہیں بدلے گا۔ allowance تب واپس آئے گی جب window reset ہو جائے گی، یا جب آپ usage credits خرید لیں گے۔

Subscription limit anay par kya karen

1. Reset ka waqt check karen. Session window mukhtasir hoti hai. Weekly window ke liye aapko apni desk par intezar karne ki zaroorat nahi hai.
2. Agar Opus limit khatam ho gayi hai, to /model chalaen aur koi doosra model muntakhib karen.
3. Apne plan ki limits, bars, aur reset ka waqt dekhne ke liye /usage chalaen. /cost bhi isi screen ka alias hai.
4. Limit se agay kaam jari rakhne ke liye /usage-credits chalaen. Pro aur Max par yeh billing settings kholta hai. Team aur Enterprise par yeh organization ki usage settings kholta hai, ya agar aapke paas billing access nahi hai to admins ko request bhejta hai.
5. Agar aap har hafte isi masle ka samna karte hain, to aapka plan aapke kaam ke mutabiq munasib nahi hai.

/usage-credits ke liye /login ke zariye sign-in ki gayi claude.ai subscription zaroori hai. API key authentication ke saath yeh dastiyab nahi hai, kyunke API key mein izafi allowance nahi hoti.

Usage credits ka ek ahem asar hai. Subscription par prompt cache ki lifetime ek ghanta hoti hai, lekin credits istemal karne par yeh घटकर 5 minute reh jati hai. Iska matlab hai ke zyada turns "cold" shuru honge aur barabar kaam ke liye Claude Code token usage barh jayega.

وہ پیغامات جو usage limits لگتے ہیں مگر حقیقت میں نہیں ہیں

Claude Code کے 4 ایررز کو usage limits کے طور پر رپورٹ کیا جاتا ہے، جبکہ وہ دراصل usage limits نہیں ہیں۔

• context یا auto-compact وارننگ usage limit نہیں ہے۔ جب گفتگو model کے context window سے بڑی ہو جاتی ہے تو /context Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue. جیسا لائن پرنٹ کرتا ہے۔ پرانی ہسٹری کو space خالی کرنے کے لیے summarize کیا جاتا ہے، اور آپ کے plan allowance پر کوئی اثر نہیں پڑتا۔
• Error during compaction: Conversation too long. Press esc twice to go up a few messages and try again. کا مطلب ہے کہ /compact خود فیل ہو گیا ہے، کیونکہ summary بنانے کے لیے کافی free context باقی نہیں ہے۔
• Credit balance is too low کا مطلب ہے کہ آپ کی Console organization کے prepaid credits ختم ہو چکے ہیں۔ platform.claude.com/settings/billing پر credits شامل کریں، جہاں auto-reload کی سہولت بھی موجود ہے۔
• API Error: Usage credits required for 1M context · run /usage-credits to turn them on, or /model to switch to standard context ایک entitlement check ہے، exhausted quota نہیں ہے۔ وہ model variant منتخب کریں جس کے ساتھ [1m] suffix نہ ہو، یا CLAUDE_CODE_DISABLE_1M_CONTEXT=1 سیٹ کریں۔

ایک اور ایرر API سے آتا ہے۔ 413 request_too_large ایک single request کی size limit ہے، rate limit نہیں ہے۔

API rate limits: 429 error ki asal wajah

Messages API teen cheezon ko alag alag model class ke liye check karti hai.

• requests per minute (RPM)
• input tokens per minute (ITPM)
• output tokens per minute (OTPM)

Aapki organization ka ek spend limit bhi hota hai, jo ke ek alag cheez hai: API usage ke liye mahana (monthly) maximum cost. Jab aap apne tier ki spend cap tak pahunch jate hain, to API usage agle mahine tak ruk jati hai, jab tak ke aap zyada limit ki request na karein. Koi bhi retry loop is masle ko hal nahi kar sakta.

Char factors tay karte hain ke 429 error kab aayega.

• Limits model class ke mutabiq hoti hain. Ye har model par alag se apply hoti hain, is liye aap ek hi waqt mein mukhtalif models ko unki apni limits tak istemal kar sakte hain. Kuch families ek hi bucket share karti hain: Opus ki rate limit Claude Opus 4.8, Opus 4.7, Opus 4.6 aur Opus 4.5 ka majmua (total) hai, jabke Claude Sonnet 5 ki apni alag limit hai.
• Capacity musalsal refill hoti hai. API token bucket algorithm istemal karti hai, is liye capacity kisi fix waqt par reset hone ke bajaye musalsal barhti rehti hai. Agar limit 60 requests per minute hai, to ye ek request per second ke taur par enforce ho sakti hai, is liye agar 60 requests ek sath bheji jayen to wo fail ho jayengi.
• Zyadatar models mein sirf uncached input ITPM mein count hota hai. input_tokens aur cache_creation_input_tokens count hote hain. Zyadatar Claude models mein cache_read_input_tokens count nahi hota, lekin Claude Haiku 3.5 iska documented exception hai. Is liye caching se rate-limit mein izafa aur discount dono milte hain. Output ki taraf, high max_tokens OTPM mein count nahi hota, kyunke OTPM sirf un tokens ko count karta hai jo asal mein produce hote hain.
• Limits organization level par hoti hain. Kisi workspace ko kam limit di ja sakti hai, aur organization-wide limits hamesha apply hoti hain, bhale hi workspace limits ka majmua zyada ho. Agar aapne kisi workspace par limit override nahi ki, to wo organization se inherit hogi, unlimited nahi hogi.

Start, Build, Scale aur Custom naam ke tiers asal numbers tay karte hain, jo aapki usage history aur account standing ke mutabiq automatically assign hote hain. Nayi organizations standard published limits se kam par shuru ho sakti hain, is liye pehla 429 error table mein di gayi maloomat se pehle aa sakta hai. Usage mein achanak izafa acceleration limits ko trigger kar deta hai, jo aapke tier ke andar hote hue bhi 429 return karte hain, is liye traffic ko ahista ahista barhayen. Har published figure ek ceiling hai: documented limits maximum allowed usage hain, guaranteed minimums nahi. Mazeed limit ke liye, Claude Console ke Limits page par "Request rate limit increase" control istemal karein.

429: retry-after، headers، اور SDK retries کو پڑھنا

ہر API error ایک ہی طرح کا envelope واپس کرتا ہے: ایک nested error object جس میں type اور message ہوتا ہے، اور ایک top-level request_id۔

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "<names the rate limit you exceeded>"
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

باقی معلومات headers میں ہوتی ہیں۔

• retry-after وہ seconds ہیں جو آپ کو request دوبارہ کرنے سے پہلے انتظار کرنے ہوں گے۔ جلد کی گئی retries fail ہو جائیں گی۔
• anthropic-ratelimit-requests-limit، anthropic-ratelimit-requests-remaining اور anthropic-ratelimit-requests-reset آپ کے request budget کی تفصیل بتاتے ہیں۔
• anthropic-ratelimit-input-tokens-* اور anthropic-ratelimit-output-tokens-* ITPM اور OTPM کے لیے وہی کام کرتے ہیں، جن میں limit، remaining اور reset suffixes استعمال ہوتے ہیں۔
• anthropic-ratelimit-tokens-* اس وقت نافذ العمل سب سے سخت limit کی values دکھاتا ہے۔

Reset headers RFC 3339 timestamps ہیں۔ Remaining token headers کو निकट ترین ہزار (thousand) تک round کیا جاتا ہے، اس لیے انہیں ایک gauge کے طور پر پڑھیں۔ Fast mode کا اپنا pool اور اپنے anthropic-fast-* headers ہوتے ہیں۔ کسی بھی successful call سے یہ تمام headers پڑھیں:

curl -s -D - -o /dev/null https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":16,"messages":[{"role":"user","content":"hi"}]}' \
  | grep -i 'ratelimit\|retry-after\|request-id'

ہر response میں ایک unique request-id header بھی ہوتا ہے، جیسے کہ req_018EeWyXxfu5pfWkrYcMdjWG۔ یہ error bodies میں request_id کے طور پر اور Python اور TypeScript SDK responses میں _request_id کے طور پر ظاہر ہوتا ہے۔ support سے رابطہ کرتے وقت اسے quote کریں۔

Backoff loop لکھنے سے پہلے یہ چیک کریں کہ کیا آپ کو اس کی ضرورت ہے یا نہیں۔ Official SDKs عارضی (transient) failures، بشمول connection errors، rate limits اور 5xx server errors، کو exponential backoff کے ساتھ خودکار طور پر retry کرتے ہیں۔ default طور پر یہ دو بار ہوتا ہے، اور اگر retry-after header موجود ہو تو اس کی پیروی کرتا ہے۔ ہر client میں maximum-retries کا option ہوتا ہے تاکہ اس behavior کو تبدیل یا disable کیا جا سکے۔

import anthropic

client = anthropic.Anthropic(max_retries=5)  # the SDK default is 2

try:
    msg = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": "hello"}],
    )
except anthropic.RateLimitError as err:
    headers = err.response.headers
    print("still limited after retries; wait", headers.get("retry-after"), "seconds")
    print("request id:", headers.get("request-id"))

529 overloaded_error آپ کی غلطی نہیں ہے

429 کا مطلب ہے کہ آپ نے درخواستیں بہت تیزی سے بھیجیں ہیں۔ 529 overloaded_error کا مطلب ہے کہ API عارضی طور پر overloaded ہے، اور یہ اس وقت ہو سکتا ہے جب تمام صارفین کی وجہ سے API پر ٹریفک زیادہ ہو۔ آپ کی key یا آپ کے code کی وجہ سے یہ مسئلہ نہیں ہوتا۔ Exponential backoff کے ساتھ دوبارہ کوشش کریں، جو SDKs پہلے سے ہی 5xx responses کے لیے کرتے ہیں، اور اگر مسئلہ حل نہ ہو تو status.claude.com چیک کریں۔ 500 api_error ایک internal error ہے جسے آپ اسی طرح دوبارہ முயற்சி کر کے حل کر سکتے ہیں، اور ان میں سے کوئی بھی rate limit نہیں ہے۔

ٹیبل کے بجائے اپنی حدود (limits) خود پڑھیں

سبسکرپشن میں، /usage وہ اسکرین ہے جو اہم ہے۔ یہ آپ کے پلان کے استعمال کے بارز (bars) اور ان کے استعمال کی تفصیل دکھاتی ہے۔ d یا w کے ذریعے آپ گزشتہ 24 گھنٹوں اور گزشتہ 7 دنوں کے درمیان سوئچ کر سکتے ہیں۔ دو اہم باتیں یاد رکھیں۔ Session بلاک API ٹوکن کے استعمال کو ظاہر کرتا ہے اور یہ API صارفین کے لیے ہے، اس لیے سبسکرائبرز اس کی ڈالر رقم کو نظر انداز کر سکتے ہیں۔ یہ اعداد و شمار اس مشین کی لوکل سیشن ہسٹری سے آتے ہیں، اس لیے دوسرے ڈیوائس یا claude.ai سے ہونے والا استعمال اس میں شامل نہیں ہوگا۔

API کے حوالے سے، Claude Console میں Usage پیج دو چارٹس دکھاتا ہے: "Rate Limit - Input Tokens" اور "Rate Limit - Output Tokens"۔ ان پٹ چارٹ فی منٹ میں uncached input tokens کی فی گھنٹہ زیادہ سے زیادہ مقدار کو آپ کی موجودہ ITPM حد کے مقابلے میں ظاہر کرتا ہے، اور اس کے ساتھ آپ کا cache rate بھی ہوتا ہے۔ اس کا مقصد یہ ہے کہ آپ پروڈکشن میں حد تک پہنچنے سے پہلے ہی اس کے قریب پہنچنے کی نگرانی کر سکیں۔

پروگرام کے ذریعے اپنی کنفیگر کی گئی حدود پڑھنے کے لیے:

curl -s https://api.anthropic.com/v1/organizations/rate_limits \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY" \
  -H "anthropic-version: 2023-06-01"

اس کے لیے Admin API key درکار ہے، اور GET /v1/organizations/workspaces/{workspace_id}/rate_limits ہر ورک اسپیس کے لیے یہی کام کرتا ہے۔ یہ دونوں read-only ہیں: حد تبدیل کرنے کے لیے، Console میں Limits ٹیب کا استعمال کریں۔

less کا استعمال کریں، تاکہ آپ کم حدوں (limits) کا سامنا کریں

دونوں سسٹمز بنیادی طور پر ایک ہی چیز کو میٹر کرتے ہیں، اس لیے یہ کنٹرولز دونوں پر کام کرتے ہیں۔

• فی ٹرن کم tokens استعمال کریں۔ مسلسل کام کرنے سے cache گرم رہتا ہے، اور غیر متعلقہ کاموں کے درمیان /clear کا کوئی خرچ نہیں ہوتا۔ Claude Code token usage ان تمام کنٹرولز کی مکمل تفصیل فراہم کرتا ہے۔
• محنت (effort) کم کریں۔ لیولز low، medium، high، xhigh اور max ہیں۔ /effort مینو میں ultracode کا آپشن بھی موجود ہے، جو خرچ کم کرنے کے بجائے اسے بڑھاتا ہے۔ کسی میکانیکی نام کی تبدیلی (mechanical rename) کے لیے گہری سوچ (deep reasoning) کی ضرورت نہیں ہے۔
• 429 ایرر کے بعد concurrency کم کریں۔ CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY کو کم کریں اور بہت زیادہ متوازی (parallel) subagents سے پرہیز کریں۔ /status بھی استعمال کریں: ایک غیر ضروری ANTHROPIC_API_KEY آپ کی سبسکرپشن کے بجائے low-tier key کے ذریعے درخواستیں بھیجتا ہے۔
• غیر انٹرایکٹو کاموں کو Message Batches API پر منتقل کریں۔ یہ بڑے حجم کے کاموں کو asynchronous طریقے سے 50% ڈسکاؤنٹ پر چلاتا ہے۔ اس کے اپنے rate limits ہوتے ہیں، اس لیے یہ آپ کے سیشن کے ساتھ مقابلہ نہیں کرتا۔

ایسا کام جو انسان کے بجائے پروگرام کے ذریعے کیا جا رہا ہو، اسے شروع سے ہی API key پر ہونا چاہیے۔ Your first Claude API app on a VPS میں key हैंडलنگ اور retries کی تفصیل موجود ہے۔ اگر آپ Claude Code running on a VPS inside tmux استعمال کرتے ہیں، تو طویل ایجنٹ رن کنکشن ٹوٹنے کے باوجود جاری رہتا ہے۔

FAQ

ماڈل تبدیل کرنے سے میرا Claude usage limit کیوں ٹھیک نہیں ہوتا؟

کیونکہ session اور weekly limits تمام ماڈلز کے لیے مشترک ہوتی ہیں۔ یہ اجازت (allowance) پلان سے وابستہ ہوتی ہے، کسی خاص ماڈل سے نہیں۔ اس لیے /model صرف یہ تبدیل کرتا ہے کہ کون سا ماڈل جواب دے گا، نہ کہ یہ کہ کتنا usage باقی ہے۔ اس کا واحد استثنا You've hit your Opus limit ہے، جو صرف Opus requests پر لاگو ہوتا ہے۔ اس صورت میں، ماڈل تبدیل کرنا ایک مستند حل ہے۔

429 rate_limit_error کا کیا مطلب ہے، اور مجھے کتنا انتظار کرنا چاہیے؟

اس کا مطلب ہے کہ آپ کا اکاؤنٹ اس ماڈل کلاس کے لیے rate limit تک پہنچ گیا ہے: یعنی per minute requests، per minute input tokens، یا per minute output tokens۔ اس response میں retry-after header ہوتا ہے جو بتاتا ہے کہ کتنے سیکنڈ انتظار کرنا ہے، اور اس سے پہلے کی retries فیل ہو جائیں گی۔ آفیشل SDKs پہلے سے ہی rate limits اور 5xx errors کے لیے exponential backoff کے ساتھ دو بار retry کرتے ہیں، اور اس header کا احترام کرتے ہیں۔ اگر آپ اپنے tier کی limits کے اندر ہوں اور پھر بھی 429 error آئے، تو اس کا مطلب ہے کہ اچانک استعمال میں اضافے کی وجہ سے acceleration limit کا سامنا ہے۔

میں اپنے Claude usage limits اور ان کے reset ہونے کا وقت کیسے دیکھ سکتا ہوں؟

Claude Code میں، اپنے پلان bars، reset times اور usage breakdown کے لیے /usage چلائیں؛ /cost ایک alias ہے، اور d یا w گزشتہ 24 گھنٹوں اور گزشتہ 7 دنوں کے درمیان سوئچ کرتا ہے۔ یہ اعداد و شمار local session history سے آتے ہیں، اس لیے ان میں دوسرے devices اور claude.ai کا usage شامل نہیں ہوتا۔ API پر، Console آپ کی rate limits کو chart کرتا ہے، اور GET /v1/organizations/rate_limits Admin API key کے ساتھ آپ کی configured limits واپس کرتا ہے۔

کیا میں Claude plan limit ختم ہونے کے بعد کام جاری رکھ سکتا ہوں؟

کبھی کبھی۔ Pro اور Max پر حد سے زیادہ usage خریدنے کے لیے، یا Team اور Enterprise پر admin سے درخواست کرنے کے لیے /usage-credits چلائیں؛ اس کے لیے /login کے ذریعے claude.ai login درکار ہے اور یہ API key authentication کے ساتھ دستیاب نہیں ہے۔ بصورتِ دیگر، reset time کا انتظار کریں، اگر یہ Opus limit تھی تو ماڈل تبدیل کریں، یا کام کو API key پر منتقل کریں، جو window کے بجائے per minute کے حساب سے میٹر کرتا ہے۔