Claude usage limit لگ جائے تو کیا کریں؟

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

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

دونوں مسائل کے حل ایک دوسرے سے مختلف ہیں۔ subscription limit کا تعلق اس بات سے ہے کہ آپ نے ایک window کے اندر کتنا استعمال کیا ہے۔ اس لیے reset کا انتظار کریں یا اضافی usage خریدیں۔ API rate limit کا تعلق آپ کی موجودہ رفتار سے ہے۔ رفتار کم کرنے کے چند seconds بعد یہ حد ختم ہو جاتی ہے۔

Plan allowances اور rate-limit tier numbers اکثر تبدیل ہوتے رہتے ہیں۔ غلط number دینے سے بہتر ہے کہ کوئی number نہ دیا جائے، اس لیے یہاں numbers درج نہیں کیے گئے۔ مزید نیچے دی گئی commands سے اپنی limits دیکھیں۔

آپ نے کون سی limit استعمال کر لی؟ عین پیغام پڑھیں

Claude Code اپنے پرنٹ کردہ متن میں system کا نام بتاتا ہے۔ کچھ تبدیل کرنے سے پہلے اپنے system کے نام کی تصدیق کریں۔

• You've hit your session limit · resets 3:45pm subscription limit ہے۔ اس window کے لیے آپ کے plan کی rolling allowance ختم ہو چکی ہے۔
• You've hit your weekly limit · resets Mon 12:00am اسی system کی طویل window والی limit ہے۔
• You've hit your Opus limit · resets 3:45pm subscription limit ہے جو صرف Opus requests پر لاگو ہوتی ہے۔ یہ واحد صورت ہے جس میں model تبدیل کرنے سے مدد ملتی ہے۔
• 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 project یا Google Cloud project کے لیے configured limit تک پہنچ گئے ہیں۔ ان میں سے کون سا لاگو ہوتا ہے، اس کا انحصار client کے authenticate ہونے کے طریقے پر ہے، کیونکہ Bedrock یا Vertex client کی metering Anthropic organization کے بجائے آپ کے cloud project کے quota کے خلاف ہوتی ہے۔
• API Error: Server is temporarily limiting requests (not your usage limit) ایک مختصر مدت کی throttle ہے جس کا آپ کے plan quota سے تعلق نہیں۔ Claude Code یہ line دکھانے سے پہلے backoff کے ساتھ خودکار طور پر retry کرتا ہے۔

سبسکرپشن کی حدود: سیشن، ہفتہ وار، اور Opus ونڈو

سبسکرپشن پلان میں مسلسل تبدیل ہونے والا usage allowance شامل ہوتا ہے۔ جب یہ allowance ختم ہو جائے تو Claude Code مزید requests کو اس reset time تک روک دیتا ہے جو message میں دکھایا جاتا ہے۔ اس allowance کی 2 خصوصیات زیادہ تر الجھن کا سبب بنتی ہیں۔

• یہ Claude chat کے ساتھ مشترک ہوتا ہے۔ claude.ai پر کیا جانے والا کام اسی allowance سے کم ہوتا ہے جس سے terminal میں کیا جانے والا کام کم ہوتا ہے، اس لیے chat میں مصروف دوپہر coding کی شام کے لیے دستیاب allowance کم کر دیتی ہے۔ اس account سے sign in کی گئی ہر surface اسی pool سے usage کم کرتی ہے، اس لیے Linux پر beta desktop app اور Claude Code CLI دونوں مل کر ایک allowance استعمال کرتے ہیں، ہر ایک کے لیے الگ allowance نہیں ہوتا۔
• یہ models کے درمیان بھی مشترک ہوتا ہے۔ Session اور weekly limits میں کسی مخصوص model کے لیے الگ budget نہیں ہوتا۔ صرف Opus limit اس سے مستثنیٰ ہے۔

Claude for Teams اور Enterprise میں documented structure کے مطابق ہر seat کے لیے ایک allowance ہوتا ہے، جو rolling five-hour window اور weekly window پر reset ہوتا ہے۔ یہ Claude chat اور Cowork کے ساتھ مشترک ہوتا ہے، اور seat tier (Standard یا Premium) کے مطابق مقرر کیا جاتا ہے۔ Pro اور Max میں message میں درج reset time اور آپ کی اپنی /usage bars ہی قابل اعتماد اعداد ہیں؛ کسی blog post سے نقل کیا گیا figure قابل اعتماد نہیں ہوتا۔ اگر آپ ابھی tier منتخب کر رہے ہیں تو آپ کو کون سا Claude plan درکار ہے ہر plan کے ذریعے محدود ہونے والی سہولیات کا تقابل کرتا ہے۔

/model سے model تبدیل کرنے پر access بحال کیوں نہیں ہوتی

یہ سب سے عام غلط اقدام ہے، اور documentation اس بارے میں واضح ہے: session اور weekly limits تمام models میں مشترک ہوتی ہیں، اس لیے model تبدیل کرنے سے access بحال نہیں ہوتی۔ session window ختم ہونے کے بعد چھوٹا model منتخب کرنے سے صرف یہ تبدیل ہوتا ہے کہ جواب کون سا model دے گا۔ باقی allowance کی مقدار تبدیل نہیں ہوتی، کیونکہ allowance کبھی بھی فی model مختص نہیں تھی۔ اس لیے switch کرنے سے release کرنے کے لیے کچھ موجود نہیں ہوتا۔

استثنا Opus limit ہے، جو واقعی model-specific حد ہے۔ اگر message You've hit your Opus limit دکھائے، تو /model درست حل ہے۔ کسی دوسرے model پر switch کریں اور کام جاری رکھیں، کیونکہ صرف Opus requests block ہوئی ہیں۔

Limit کو bug سمجھنا دوسری عام غلطی ہے۔ دوبارہ install کرنے یا دوبارہ authenticate کرنے سے کچھ تبدیل نہیں ہوتا۔ allowance window reset ہونے پر، یا usage credits خریدنے پر واپس آتی ہے۔

سبسکرپشن کی حد پوری ہونے پر کیا کریں

1. ری سیٹ کا وقت دیکھیں۔ سیشن ونڈو مختصر ہوتی ہے۔ ہفتہ وار ونڈو ایسی چیز نہیں جس کے ختم ہونے کا انتظار آپ اپنی میز پر بیٹھ کر کریں۔
2. اگر یہ Opus کی حد ہے تو /model چلائیں اور دوسرا ماڈل منتخب کریں۔
3. اپنے پلان کی حدود، استعمال کی سلاخیں اور ری سیٹ کا وقت دیکھنے کے لیے /usage چلائیں۔ /cost اسی اسکرین کا alias ہے۔
4. حد سے آگے کام جاری رکھنے کے لیے /usage-credits چلائیں۔ Pro اور Max میں یہ آپ کی billing settings کھولتا ہے۔ Team اور Enterprise میں یہ آپ کی تنظیم کی usage settings کھولتا ہے، یا اگر آپ کے پاس billing access نہیں ہے تو administrators کو درخواست بھیجتا ہے۔
5. اگر ہر ہفتے یہی حد پوری ہو جاتی ہے تو آپ کے کام کے طریقے کے لیے یہ پلان مناسب سائز کا نہیں ہے۔ usage limit سے نکلنے کے طریقے ہر ری سیٹ کے وقت دوبارہ غور کرنے کے بجائے ایک مرتبہ جانچنے کے قابل ہیں۔

/usage-credits کے لیے /login کے ذریعے sign in کی گئی claude.ai subscription ضروری ہے۔ API key authentication کے ساتھ یہ دستیاب نہیں ہے، کیونکہ API key میں بڑھانے کے لیے کوئی plan allowance نہیں ہوتا۔

Usage credits کا ایک ضمنی اثر ہے جسے پہلے جاننا ضروری ہے۔ Subscription پر prompt cache کی مدت ایک گھنٹہ ہوتی ہے، لیکن credits استعمال شروع کرنے پر یہ کم ہو کر پانچ منٹ رہ جاتی ہے۔ اس لیے زیادہ turns شروع سے چلتے ہیں اور اسی کام کے لیے Claude Code token usage بڑھ جاتا ہے۔

وہ پیغامات جو usage limits جیسے دکھائی دیتے ہیں، مگر usage limits نہیں ہیں

Claude Code کی 4 errors کو usage limits کے طور پر رپورٹ کیا جاتا ہے، حالانکہ ان میں سے کوئی بھی usage limit نہیں ہے۔

• Context یا auto-compact warning usage limit نہیں ہوتی۔ /context اس وقت Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue. جیسی سطر دکھاتا ہے جب conversation model کی context window سے بڑھ جائے۔ پرانی history کا خلاصہ بنا کر جگہ خالی کی جاتی ہے، جبکہ آپ کے plan کا allowance متاثر نہیں ہوتا۔
• Error during compaction: Conversation too long. Press esc twice to go up a few messages and try again. کا مطلب ہے کہ خود /compact ناکام ہو گیا، کیونکہ اس سے بننے والے خلاصے کے لیے باقی context میں کافی جگہ موجود نہیں تھی۔
• Credit balance is too low کا مطلب ہے کہ آپ کی Console organization کے prepaid credits ختم ہو گئے ہیں۔ credits شامل کرنے کے لیے platform.claude.com/settings/billing پر جائیں۔ وہاں 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 ہے، ختم شدہ quota نہیں۔ [1m] suffix کے بغیر model variant منتخب کریں، یا CLAUDE_CODE_DISABLE_1M_CONTEXT=1 set کریں۔

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

API rate limits: 429 اصل میں کیا شمار کرتا ہے

Messages API ہر model class کے لیے الگ الگ تین چیزیں ناپتی ہے۔

• فی منٹ requests (RPM)
• فی منٹ input tokens (ITPM)
• فی منٹ output tokens (OTPM)

آپ کی organization کے لیے spend limit بھی مقرر ہوتی ہے، لیکن یہ الگ چیز ہے: API استعمال کی ماہانہ زیادہ سے زیادہ لاگت۔ جب آپ اپنی tier کی spend cap تک پہنچ جاتے ہیں تو API کا استعمال اگلے ماہ تک رک جاتا ہے، جب تک کہ آپ زیادہ limit کی درخواست نہ کریں۔ کوئی retry loop اس مسئلے کو حل نہیں کر سکتا۔

چار mechanisms طے کرتے ہیں کہ 429 کب آتا ہے۔

• Limits ہر model class کے لیے الگ ہوتی ہیں۔ یہ ہر model پر الگ لاگو ہوتی ہیں، اس لیے آپ مختلف models کو ان کی متعلقہ limits تک بیک وقت استعمال کر سکتے ہیں۔ کچھ families ایک ہی bucket شیئر کرتی ہیں: Opus rate limit، Claude Opus 4.8، Opus 4.7، Opus 4.6 اور Opus 4.5 سب کے لیے مجموعی ہوتی ہے، جبکہ Claude Sonnet 5 کی اپنی الگ limit ہے۔
• Capacity مسلسل refill ہوتی ہے۔ API token bucket algorithm استعمال کرتی ہے، اس لیے capacity کسی مقررہ وقت پر reset ہونے کے بجائے مسلسل بحال ہوتی رہتی ہے۔ 60 requests فی منٹ کی limit کو ایک request فی second کے طور پر نافذ کیا جا سکتا ہے، اس لیے ایک ہی وقت میں بھیجی گئی 60 requests ناکام ہو سکتی ہیں۔
• زیادہ تر models میں ITPM کے لیے صرف uncached input شمار ہوتا ہے۔ input_tokens اور cache_creation_input_tokens شمار ہوتے ہیں۔ زیادہ تر Claude models میں cache_read_input_tokens شمار نہیں ہوتا؛ Claude Haiku 3.5 اس کی documented exception ہے۔ اس لیے caching سے discount کے علاوہ rate-limit headroom بھی ملتا ہے۔ output کے معاملے میں زیادہ max_tokens، OTPM کے خلاف شمار نہیں ہوتا، کیونکہ OTPM صرف حقیقت میں تیار کیے گئے tokens شمار کرتا ہے۔
• Limits organization level پر موجود ہوتی ہیں۔ کسی workspace کو کم limit دی جا سکتی ہے، اور organization-wide limits ہمیشہ لاگو ہوتی ہیں، چاہے workspace limits کا مجموعہ اس سے زیادہ ہو۔ workspace پر override نہ کی گئی limit organization سے inherit ہوتی ہے؛ اسے unlimited نہیں سمجھا جاتا۔

Start، Build، Scale اور Custom نام کی tiers اصل اعداد مقرر کرتی ہیں۔ یہ tiers آپ کی usage history اور account standing کی بنیاد پر خودکار طور پر assign ہوتی ہیں۔ نئی organizations standard published limits سے کم سطح پر شروع ہو سکتی ہیں، اس لیے پہلا 429 table کی پیش گوئی سے پہلے آ سکتا ہے۔ usage میں اچانک اضافہ acceleration limits کو متحرک کرتا ہے۔ اس صورت میں آپ اپنی tier کے اندر رہتے ہوئے بھی 429 حاصل کر سکتے ہیں، اس لیے traffic کو بتدریج بڑھائیں۔ ہر published figure ایک ceiling ہے: documented limits زیادہ سے زیادہ مجاز usage ہیں، guaranteed minimums نہیں۔ زیادہ limit کی درخواست کرنے کے لیے Claude Console میں Limits page پر موجود "Request rate limit increase" control استعمال کریں۔

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 ناکام ہوں گی۔
• anthropic-ratelimit-requests-limit، anthropic-ratelimit-requests-remaining اور anthropic-ratelimit-requests-reset آپ کے request budget کی تفصیل دیتے ہیں۔
• anthropic-ratelimit-input-tokens-* اور anthropic-ratelimit-output-tokens-* ITPM اور OTPM کے لیے یہی معلومات دیتے ہیں، جن کے suffixes limit، remaining اور reset ہیں۔
• anthropic-ratelimit-tokens-* اس وقت نافذ سب سے سخت limit کی values دکھاتا ہے۔

Reset headers RFC 3339 timestamps ہوتے ہیں۔ Remaining token headers قریب ترین thousand تک round کیے جاتے ہیں، اس لیے انہیں ایک gauge کے طور پر پڑھیں۔ Fast mode کا اپنا pool اور اپنے anthropic-fast-* headers ہوتے ہیں۔ کامیاب 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 میں ایک منفرد request-id header بھی ہوتا ہے، مثلاً req_018EeWyXxfu5pfWkrYcMdjWG۔ Error bodies میں یہ request_id کے طور پر اور Python اور TypeScript SDK responses میں _request_id کے طور پر ظاہر ہوتا ہے۔ Support سے رابطہ کرتے وقت اسے ضرور فراہم کریں۔

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

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 کو تمام صارفین کی جانب سے network traffic بہت زیادہ موصول ہو۔ اس کی وجہ آپ کی key یا code نہیں ہے۔ Exponential backoff کے ساتھ دوبارہ کوشش کریں۔ SDKs پہلے ہی 5xx responses کے لیے ایسا کرتے ہیں۔ اگر مسئلہ برقرار رہے تو status.claude.com دیکھیں۔ 500 api_error اندرونی error ہے۔ اس میں بھی اسی طرح دوبارہ کوشش کریں۔ ان دونوں میں سے کوئی بھی rate limit نہیں ہے۔

اپنی حدود خود دیکھیں، صرف جدول پر انحصار نہ کریں

سبسکرپشن میں /usage وہ اسکرین ہے جو اہمیت رکھتی ہے۔ اس میں آپ کے پلان کے استعمال کے بارز اور یہ تفصیل دکھائی جاتی ہے کہ ان کا استعمال کس چیز نے کیا۔ d یا w کے ذریعے گزشتہ 24 گھنٹوں اور گزشتہ 7 دنوں کے درمیان تبدیل کیا جا سکتا ہے۔ دو باتیں ذہن میں رکھیں۔ Session بلاک API token کے استعمال کو دکھاتا ہے اور API صارفین کے لیے ہے، اس لیے subscribers اس میں دکھائی گئی dollar figure کو نظر انداز کر سکتے ہیں۔ یہ اعداد اس مشین کی local session history سے حاصل ہوتے ہیں، اس لیے کسی دوسری device یا claude.ai کا استعمال شامل نہیں ہوتا۔

API کی جانب سے Claude Console کا Usage صفحہ دو charts دکھاتا ہے: "Rate Limit - Input Tokens" اور "Rate Limit - Output Tokens"۔ Input chart ہر گھنٹے uncached input tokens per minute کی زیادہ سے زیادہ مقدار کو آپ کی موجودہ ITPM limit کے مقابل دکھاتا ہے۔ اس کے ساتھ cache rate بھی دکھائی جاتی ہے۔ اس طرح آپ production میں limit سے ٹکرانے کے بجائے اس کے قریب پہنچنے کی نگرانی کر سکتے ہیں۔

اپنی configured limits کو programmatically پڑھنے کے لیے:

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 ہر workspace کے لیے یہی کام کرتا ہے۔ دونوں صرف read-only ہیں۔ کسی limit کو تبدیل کرنے کے لیے Console میں Limits tab استعمال کریں۔

کم استعمال کریں تاکہ limits کم پیش آئیں

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

• ہر turn میں کم tokens خرچ کریں۔ مسلسل کام کرنے سے cache گرم رہتا ہے، اور غیر متعلقہ tasks کے درمیان /clear کی کوئی لاگت نہیں ہوتی۔ Claude Code کے token usage میں ان طریقوں کی مکمل وضاحت ہے۔
• effort کم کریں۔ levels low، medium، high، xhigh اور max ہیں۔ /effort menu میں ultracode بھی موجود ہے، جو خرچ کم کرنے کے بجائے بڑھاتا ہے۔ معمولی rename کے لیے گہری reasoning سے کوئی فائدہ نہیں ہوتا۔
• 429 کے بعد concurrency کم کریں۔ CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY کم کریں اور بہت سے parallel subagents سے گریز کریں۔ /status بھی چلائیں: کوئی غیر مطلوب ANTHROPIC_API_KEY requests کو آپ کی subscription کے بجائے low-tier key کے ذریعے route کر سکتا ہے۔
• غیر تعاملی کام کو Message Batches API پر منتقل کریں۔ یہ بڑے volumes کو asynchronously چلاتی ہے اور input اور output tokens پر 50% discount دیتی ہے۔ اس کی rate limits الگ ہوتی ہیں، اس لیے nightly job آپ کے session سے مقابلہ نہیں کرتی۔

جو کام context میں بہت سا data داخل کرتا ہے، اس پر یہ مسئلہ سب سے زیادہ محسوس ہوتا ہے۔ اگر آپ live market data کے مقابل stocks اور options کا تجزیہ کر رہے ہیں تو ہر سوال کے لیے درکار محدود data حاصل کرنے کی لاگت، quotes اور chains کی مکمل tables paste کرنے کے مقابلے میں بہت کم ہوتی ہے۔ کسی شخص کے بجائے program سے چلنے والا bursty کام ابتدا ہی سے API key پر ہونا چاہیے۔ وہاں منتقل ہونے سے ادائیگی کا طریقہ بھی بدلتا ہے اور metering کا طریقہ بھی، کیونکہ Claude API میں free tier نہیں ہے، سوائے signup پر ملنے والے معمولی credit کے۔ VPS پر اپنی پہلی Claude API app میں key handling اور retries کی وضاحت ہے، جبکہ طویل agent run اس وقت بھی جاری رہتا ہے جب connection منقطع ہو جائے، بشرطیکہ آپ tmux کے اندر VPS پر Claude Code چلا رہے ہوں۔

FAQ

میرے Claude استعمال کی حد ماڈل تبدیل کرنے سے کیوں ختم نہیں ہوتی؟

کیونکہ session اور ہفتہ وار limits تمام models میں مشترک ہوتی ہیں۔ allowance plan سے وابستہ ہوتا ہے، model سے نہیں۔ اس لیے /model صرف یہ تبدیل کرتا ہے کہ جواب کون سا model دے گا، یہ نہیں کہ باقی allowance کتنی ہے۔ واحد استثنا You've hit your Opus limit ہے، جو صرف Opus requests پر لاگو ہوتا ہے۔ اس صورت میں model تبدیل کرنا documented حل ہے۔

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

اس کا مطلب ہے کہ آپ کا account اس model class کی rate limit تک پہنچ گیا ہے: فی منٹ requests، فی منٹ input tokens، یا فی منٹ output tokens۔ response میں retry-after header شامل ہوتا ہے، جس میں انتظار کے seconds درج ہوتے ہیں، اور اس سے پہلے کی retries ناکام ہو جاتی ہیں۔ official SDKs rate limits اور 5xx errors کے لیے exponential backoff کے ساتھ خودکار retry کرتے ہیں۔ default طور پر یہ دو بار retry کرتے ہیں اور اس header کی پابندی کرتے ہیں۔ اگر 429 آپ کی tier limits کے اندر رہتے ہوئے موصول ہو تو یہ اچانک ramp کی وجہ سے acceleration limit کی نشاندہی کرتا ہے۔

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

Claude Code میں اپنے plan bars، reset times اور usage breakdown دیکھنے کے لیے /usage چلائیں۔ /cost اس کا alias ہے، جبکہ d یا w آخری 24 hours اور آخری 7 days کے درمیان switch کرتا ہے۔ یہ اعداد و شمار مقامی session history سے حاصل ہوتے ہیں، اس لیے ان میں دیگر devices اور claude.ai کا استعمال شامل نہیں ہوتا۔ API میں Console آپ کی rate limits کے charts دکھاتا ہے، جبکہ GET /v1/organizations/rate_limits Admin API key کے ذریعے configured limits واپس کرتا ہے۔

کیا Claude plan limit تک پہنچنے کے بعد بھی کام جاری رکھا جا سکتا ہے؟

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