Claude usage limits कैसे ठीक करें

Claude की usage limits क्या हैं?

Claude की usage limits दो अलग-अलग systems में काम करती हैं। सबसे पहले यह पहचानना ज़रूरी है कि कौन सा system आपको रोक रहा है। Claude subscription (Pro, Max, Team, या Enterprise) आपको एक rolling usage allowance देता है। यह allowance सभी models और Claude chat के बीच shared होता है, इसलिए यह आपको You've hit your session limit · resets 3:45pm जैसे message के साथ रोकता है। Claude API किसी और चीज़ को measure करता है: आप कितनी तेज़ी से requests और tokens भेजते हैं, जिसे प्रति minute count किया जाता है। यह आपको rate_limit_error प्रकार के HTTP 429 error और एक retry-after header के साथ रोकता है, जो बताता है कि कितने seconds तक इंतज़ार करना है।

इन दोनों के solutions पूरी तरह अलग हैं। Subscription limit इस बात पर निर्भर करती है कि आपने एक window के भीतर कितना use किया है, इसलिए आपको reset होने का इंतज़ार करना होगा या अधिक usage खरीदना होगा। API rate limit आपकी वर्तमान speed पर निर्भर करती है, और जैसे ही आप speed कम करते हैं, यह seconds में clear हो जाती है।

Plan allowances और rate-limit tier numbers अक्सर बदलते रहते हैं। गलत number बता देना न बताने से भी बुरा है, इसलिए यहाँ कोई भी number नहीं दिया गया है। नीचे दिए गए commands के साथ अपना data स्वयं पढ़ें।

आपने किस limit को पार कर लिया है? सटीक message पढ़ें

Claude Code अपने text में 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 लंबे window वाला वही system है।
• You've hit your Opus limit · resets 3:45pm एक subscription limit है जो केवल Opus requests पर लागू होती है। यह एकमात्र case है जहाँ 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 या Google Cloud project के लिए configured limit को पार कर लिया है।
• API Error: Server is temporarily limiting requests (not your usage limit) एक short-lived throttle है जो आपके plan quota से संबंधित नहीं है। Claude Code उस line को दिखाने से पहले automatic backoff के साथ इसे retry करता है।

Subscription limits: session, weekly, and the Opus window

Subscription plan में एक rolling usage allowance मिलता है। जब यह समाप्त हो जाता है, तो Claude Code संदेश में दिखाए गए reset time तक आगे के requests को ब्लॉक कर देता है। इस allowance की दो properties के कारण अक्सर भ्रम होता है।

• यह Claude chat के साथ shared है। claude.ai पर किया गया कार्य और terminal में किया गया कार्य एक ही allowance का उपयोग करते हैं, इसलिए chat में अधिक उपयोग करने से आपके coding session का समय कम हो जाता है।
• यह models के बीच shared है। Session और weekly limits में प्रति-model बजट नहीं होता है, केवल Opus limit इसका अपवाद है।

Claude for Teams और Enterprise में, documented structure प्रति-seat allowance का है जो एक rolling five-hour window और एक weekly window पर reset होता है। यह Claude chat और Cowork के साथ shared है, और seat tier (Standard या Premium) के अनुसार निर्धारित होता है। Pro और Max में, संदेश में दिया गया reset time और आपके अपने /usage bars ही सटीक जानकारी हैं, न कि किसी blog post से ली गई संख्या। यदि आप अभी भी tier चुन रहे हैं, तो आपको कौन सा Claude plan चाहिए का उपयोग करें, जो प्रत्येक plan की सीमाओं की तुलना करता है।

/model के साथ model बदलने पर access क्यों बहाल नहीं होता

यह सबसे सामान्य गलती है, और documentation इस बारे में स्पष्ट है: session और weekly limits सभी models के लिए साझा (shared) होती हैं, इसलिए model बदलने से access बहाल नहीं होता। session window समाप्त होने के बाद छोटा model चुनना केवल यह बदलता है कि कौन सा model उत्तर देगा। यह शेष allowance को नहीं बदलता, क्योंकि allowance कभी भी per model नहीं रखा गया था, इसलिए switch करने पर कुछ भी release नहीं होगा।

इसका अपवाद Opus limit है, जो वास्तव में model-specific ceiling है। यदि message में You've hit your Opus limit लिखा है, तो /model सही समाधान है। किसी अन्य model पर switch करें और काम जारी रखें, क्योंकि केवल Opus requests ही block हुई थीं।

Limit को bug समझना दूसरी गलती है। Reinstalling या re-authenticating करने से कुछ नहीं बदलेगा। Allowance तब वापस आता है जब window reset होती है, या जब आप usage credits खरीदते हैं।

Subscription limit आने पर क्या करें

1. Reset time देखें। Session window छोटा होता है। Weekly window के लिए आपको अपनी डेस्क पर बैठने की आवश्यकता नहीं है।
2. यदि Opus limit आ गई है, तो /model चलाएँ और दूसरा model चुनें।
3. अपने plan limits, bars, और reset time देखने के लिए /usage चलाएँ। /cost उसी screen का alias है।
4. Limit से आगे काम जारी रखने के लिए /usage-credits चलाएँ। Pro और Max पर यह आपके billing settings खोलता है। Team और Enterprise पर यह आपकी organization के usage settings खोलता है, या यदि आपके पास billing access नहीं है, तो admins को request भेजता है।
5. यदि आप हर हफ्ते एक ही limit पर पहुँच जाते हैं, तो आपका plan आपके workflow के लिए सही नहीं है।

/usage-credits के लिए /login के माध्यम से signed in claude.ai subscription आवश्यक है। API key authentication के साथ यह उपलब्ध नहीं है, क्योंकि API key में extend करने के लिए कोई plan allowance नहीं होता है।

Usage credits का एक side effect है जिसे जानना महत्वपूर्ण है। Subscription पर prompt cache lifetime एक घंटा होती है, लेकिन credits का उपयोग करते समय यह घटकर पाँच मिनट हो जाती है। इसके कारण अधिक turns 'cold' शुरू होते हैं और समान कार्य के लिए Claude Code token usage बढ़ जाता है।

वे messages जो usage limits की तरह दिखते हैं पर वास्तव में नहीं हैं

Claude Code में चार errors को usage limits के रूप में दिखाया जाता है, जबकि वे वास्तव में limits नहीं हैं।

• Context या auto-compact warning usage limit नहीं है। जब conversation model के context window से बड़ा हो जाता है, तब /context Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue. जैसा line प्रिंट करता है। Space खाली करने के लिए पुरानी history को summarize किया जाता है, और आपके plan allowance पर कोई असर नहीं पड़ता।
• Error during compaction: Conversation too long. Press esc twice to go up a few messages and try again. का मतलब है कि /compact fail हो गया है, क्योंकि 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 नहीं। बिना [1m] suffix वाला model variant चुनें, या CLAUDE_CODE_DISABLE_1M_CONTEXT=1 सेट करें।

एक error API से आता है। 413 request_too_large एक single request की size limit है, rate limit नहीं।

API rate limits: 429 error का वास्तविक कारण

Messages API तीन अलग-अलग चीजों को मापता है, जो प्रत्येक model class के लिए अलग होती हैं:

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

आपकी organization की एक spend limit भी होती है, जो एक अलग चीज़ है: API usage के लिए अधिकतम मासिक लागत। एक बार जब आप अपने tier की spend cap तक पहुँच जाते हैं, तो API usage अगले महीने तक रुक जाता है, जब तक कि आप उच्च limit का अनुरोध न करें। कोई भी retry loop इस समस्या को हल नहीं कर सकता।

429 error कब आएगा, यह चार mechanics तय करते हैं:

• Limits model class के अनुसार होती हैं। ये प्रत्येक model पर अलग से लागू होती हैं, इसलिए आप एक ही समय में अपने संबंधित limits तक अलग-अलग models का उपयोग कर सकते हैं। कुछ 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 per minute की limit को एक request per second के रूप में लागू किया जा सकता है, इसलिए यदि 60 requests एक साथ भेजी जाती हैं, तो वे fail हो जाएंगी।
• अधिकांश models पर केवल uncached input ही ITPM में गिना जाता है। input_tokens और cache_creation_input_tokens गिने जाते हैं। अधिकांश Claude models में cache_read_input_tokens नहीं गिना जाता है, जिसमें Claude Haiku 3.5 एक documented exception है। इसलिए caching से rate-limit headroom और discount दोनों मिलते हैं। Output की बात करें तो, उच्च max_tokens OTPM में नहीं गिना जाता है, क्योंकि OTPM केवल वास्तव में produce किए गए tokens को गिनता है।
• Limits organization level पर लागू होती हैं। एक workspace को कम limit दी जा सकती है, और organization-wide limits हमेशा लागू होती हैं, भले ही workspace limits का योग अधिक हो। यदि आपने किसी workspace पर limit को override नहीं किया है, तो वह organization से inherit होती है, वह unlimited नहीं होती।

Start, Build, Scale और Custom नाम के tiers वास्तविक संख्याएँ निर्धारित करते हैं, जो आपके usage history और account standing के आधार पर स्वचालित रूप से assign किए जाते हैं। नए organizations मानक published limits से नीचे शुरू हो सकते हैं, इसलिए पहला 429 error किसी table के अनुमान से पहले आ सकता है। Usage में अचानक वृद्धि acceleration limits को trigger करती है, जो आपके tier के भीतर होने पर भी 429 return करती हैं, इसलिए traffic को धीरे-धीरे बढ़ाएं। प्रत्येक published figure एक ceiling है: documented limits अधिकतम अनुमत usage हैं, गारंटीकृत 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 retry करने से पहले wait करने होंगे। पहले की गई 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-* वर्तमान में प्रभावी सबसे restrictive limit के values दिखाता है।

Reset headers RFC 3339 timestamps हैं। Remaining token headers को nearest thousand तक round किया जाता है, इसलिए इन्हें एक gauge की तरह पढ़ें। Fast mode का अपना pool और अपने anthropic-fast-* headers होते हैं। किसी भी successful call से इन्हें पढ़ें:

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 में इस behavior को बदलने या disable करने के लिए 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 का अर्थ है कि आपने बहुत तेज़ी से अनुरोध (requests) भेजे हैं। 529 overloaded_error का अर्थ है कि API अस्थायी रूप से ओवरलोड है। यह तब हो सकता है जब सभी उपयोगकर्ताओं के कारण API पर ट्रैफ़िक बहुत अधिक हो। यह आपके key या आपके code के कारण नहीं होता है। exponential backoff के साथ पुनः प्रयास (retry) करें, जो SDKs पहले से ही 5xx responses के लिए करते हैं, और यदि समस्या बनी रहती है तो status.claude.com चेक करें। 500 api_error एक internal error है जिसे आप उसी तरह retry कर सकते हैं, और इनमें से कोई भी rate limit नहीं है।

Table के बजाय अपने स्वयं के limits को पढ़ें

Subscription में, /usage सबसे महत्वपूर्ण screen है। यह आपके plan usage bars और खपत का विवरण दिखाता है। इसमें d या w के माध्यम से पिछले 24 घंटों और पिछले 7 दिनों के बीच स्विच किया जा सकता है। दो महत्वपूर्ण बातें। Session block API token usage दिखाता है और यह API users के लिए है, इसलिए subscribers इसके dollar figure को अनदेखा कर सकते हैं। ये आंकड़े उस machine के local session history से आते हैं, इसलिए दूसरे device या claude.ai से हुआ usage इसमें शामिल नहीं होगा।

API के मामले में, Claude Console का Usage page दो charts बनाता है: "Rate Limit - Input Tokens" और "Rate Limit - Output Tokens"। Input chart प्रति minute uncached input tokens के hourly maximum को आपके वर्तमान ITPM limit के विरुद्ध प्लॉट करता है। इसके साथ आपका cache rate भी दिखाया जाता है, ताकि आप production में limit तक पहुँचने से पहले ही उसे देख सकें।

Programmatically अपने configured limits पढ़ने के लिए:

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 का उपयोग करें।

less का उपयोग करें, ताकि आप सीमाओं (limits) से बच सकें

दोनों systems आंतरिक रूप से एक ही चीज़ को मापते हैं, इसलिए ये levers दोनों पर काम करते हैं।

• प्रति turn कम tokens खर्च करें। लगातार काम करने से cache warm रहता है, और असंबंधित tasks के बीच /clear करने में कोई लागत नहीं आती। Claude Code token usage इन levers की पूरी जानकारी देता है।
• Effort कम करें। Levels low, medium, high, xhigh और max हैं। /effort menu में ultracode का विकल्प भी है, जो खर्च को कम करने के बजाय बढ़ाता है। किसी mechanical rename के लिए deep reasoning की आवश्यकता नहीं है।
• 429 error के बाद concurrency कम करें। CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY को कम करें और कई parallel subagents से बचें। /status का भी उपयोग करें: एक stray ANTHROPIC_API_KEY आपके subscription के बजाय low-tier key के माध्यम से requests भेजता है।
• Non-interactive work को Message Batches API पर ले जाएँ। यह input और output tokens पर 50% discount के साथ बड़े volumes को asynchronously चलाता है। इसके अपने rate limits होते हैं, जिससे nightly job आपके session के साथ compete नहीं करता।

किसी व्यक्ति के बजाय program द्वारा संचालित bursty work के लिए शुरुआत से ही API key का उपयोग करना चाहिए। Your first Claude API app on a VPS key handling और retries के बारे में बताता है, और Claude Code running on a VPS inside tmux का उपयोग करने पर connection टूटने पर भी long agent run चलता रहता है।

FAQ

मॉडल बदलने से मेरी Claude usage limit क्यों ठीक नहीं होती?

क्योंकि session और weekly limits सभी models के लिए साझा (shared) होती हैं। यह allowance आपके plan से जुड़ी होती है, न कि किसी विशेष model से। इसलिए /model बदलने से केवल यह तय होता है कि कौन सा model उत्तर देगा, न कि आपकी बची हुई allowance। इसका एकमात्र अपवाद You've hit your Opus limit है, जो केवल Opus requests पर लागू होता है। उस स्थिति में, model बदलना एक प्रमाणित समाधान है।

429 rate_limit_error का क्या अर्थ है, और मुझे कितनी देर प्रतीक्षा करनी चाहिए?

इसका अर्थ है कि आपका account उस model class के लिए निर्धारित rate limit तक पहुँच गया है: जैसे प्रति मिनट requests, प्रति मिनट input tokens, या प्रति मिनट output tokens। response में एक retry-after header मिलता है जिसमें प्रतीक्षा करने के सेकंड दिए होते हैं, और उससे पहले किए गए retries विफल हो जाते हैं। आधिकारिक SDKs पहले से ही exponential backoff के साथ rate limits और 5xx errors को retry करते हैं, जो डिफ़ॉल्ट रूप से दो बार उस header का पालन करते हैं। यदि आप अपने tier की limits के भीतर हैं और फिर भी 429 error आता है, तो यह अचानक बढ़े हुए traffic के कारण acceleration limit का संकेत है।

मैं अपनी Claude usage limits और उनके reset होने का समय कैसे देख सकता हूँ?

Claude Code में, अपने plan 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 पर ceiling से अधिक usage खरीदने के लिए, या Team और Enterprise पर admin से अनुरोध करने के लिए /usage-credits चलाएँ; इसके लिए /login के माध्यम से claude.ai login की आवश्यकता होती है और यह API key authentication के साथ उपलब्ध नहीं है। अन्यथा, reset time तक प्रतीक्षा करें, यदि यह Opus limit थी तो model बदलें, या काम को API key पर स्थानांतरित करें, जो window के बजाय प्रति मिनट के आधार पर meter करता है।