SSD Nodes Learn Hosting plans →
गाइड Matt Connorलेखक: Matt Connor

Claude usage limit कैसे ठीक करें: पूरी जानकारी

Claude में You've hit your session limit या API 429 error आने पर क्या करें। जानें कि subscription और API rate limits में क्या अंतर है और इन्हें कैसे हल किया जाता है।

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

Claude की usage limits दो अलग-अलग प्रणालियों में आती हैं, और पहला काम यह पता लगाना है कि किस कारण से आप रुके हैं। एक Claude subscription (Pro, Max, Team, या seat-based Enterprise) आपको एक rolling usage allowance देता है जो कुछ model-family ceilings को छोड़कर सभी models के बीच साझा होता है, और यह Claude chat के साथ भी साझा होता है, इसलिए यह आपको You've hit your session limit · resets 3:45pm जैसे संदेश के साथ रोकता है। वर्तमान usage-based Enterprise plans इसके अपवाद हैं: इनमें कोई allowance शामिल नहीं होता, और सारा usage पहले token से ही API rates पर बिल किया जाता है। Claude API कुछ और मापता है: आप कितनी तेजी से requests और tokens भेजते हैं, जिसे प्रति मिनट गिना जाता है। यह आपको rate_limit_error प्रकार की HTTP 429 error के साथ रोकता है, जिसमें आमतौर पर एक retry-after header होता है जो बताता है कि कितने सेकंड प्रतीक्षा करनी है।

इनके समाधानों में कुछ भी समान नहीं है। Subscription limit इस बारे में है कि आपने एक निश्चित अवधि के भीतर कितना उपयोग किया है, इसलिए आप reset होने की प्रतीक्षा करते हैं, अधिक usage खरीदते हैं, या यदि आपके plan में विकल्प है तो free limit reset का उपयोग करते हैं। API rate limit आपकी वर्तमान गति के बारे में है, और गति धीमी करने पर यह कुछ ही सेकंड में ठीक हो जाती है।

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

आपने कौन सी सीमा पार की है? सटीक संदेश पढ़ें

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 अनुरोधों पर लागू होती है। Opus परिवार से बाहर के मॉडल पर स्विच करने से आप काम जारी रख सकते हैं।
  • You've hit your Sonnet limit · resets 3:45pm इसी तरह की मॉडल-फैमिली सीमा है, जो केवल Sonnet अनुरोधों के लिए है। Sonnet परिवार से बाहर के मॉडल पर स्विच करने से आप काम जारी रख सकते हैं।
  • यदि कोई संदेश Fable limit reached से शुरू होता है, तो इसका मतलब है कि आपने अपने साप्ताहिक अलाउंस का वह हिस्सा उपयोग कर लिया है जो Fable मॉडल ले सकते हैं। Fable पर काम जारी रखने से उपयोग क्रेडिट (usage credits) खर्च होते हैं, इसलिए Claude Code पहले आपसे पुष्टि करने के लिए कहता है। अपनी योजना के भीतर रहने के लिए /model के साथ कोई अन्य मॉडल चुनें।
  • API Error: Request rejected (429) · this may be a temporary capacity issue. If it persists, check https://status.claude.com. एक API रेट लिमिट है। आपने अपनी API key, या अपने Amazon Bedrock या Google Cloud प्रोजेक्ट के लिए कॉन्फ़िगर की गई सीमा को पार कर लिया है। इनमें से कौन सा लागू होता है, यह इस बात पर निर्भर करता है कि क्लाइंट ऑथेंटिकेट कैसे करता है, क्योंकि Bedrock या Vertex क्लाइंट को Anthropic संगठन के बजाय आपके क्लाउड प्रोजेक्ट के कोटा के विरुद्ध मापा जाता है।
  • API Error: Server is temporarily limiting requests (not your usage limit) एक अल्पकालिक थ्रॉटल है जो आपके प्लान कोटा से संबंधित नहीं है। Claude Code उस लाइन को दिखाने से पहले बैकऑफ़ के साथ इसे स्वचालित रूप से पुनः प्रयास (retry) करता है।

सब्सक्रिप्शन सीमाएं: सेशन, साप्ताहिक, और Opus विंडो

Pro, Max, Team या सीट-आधारित Enterprise प्लान में एक रोलिंग यूसेज अलाउंस (rolling usage allowance) शामिल होता है। जब यह समाप्त हो जाता है, तो Claude Code संदेश में दिखाए गए रीसेट समय तक आगे के अनुरोधों को ब्लॉक कर देता है। इस अलाउंस की दो विशेषताएं सबसे अधिक भ्रम पैदा करती हैं।

  • यह Claude चैट के साथ साझा किया जाता है। claude.ai पर किया गया आपका काम टर्मिनल में किए गए काम के समान अलाउंस से ही खर्च होता है, इसलिए चैट में बिताई गई एक भारी दोपहर आपके कोडिंग की शाम को छोटा कर देती है। जिस भी इंटरफेस में आप उस अकाउंट से साइन इन करते हैं, वह एक ही पूल से खर्च होता है, इसलिए Linux पर बीटा डेस्कटॉप ऐप और Claude Code CLI दोनों एक ही अलाउंस का उपयोग करते हैं, अलग-अलग नहीं।
  • यह सभी मॉडल्स के बीच साझा किया जाता है। सेशन और साप्ताहिक सीमाएं हर मॉडल के लिए एक ही पूल हैं। इसके अपवाद उस पूल के भीतर मॉडल-फैमिली की अधिकतम सीमाएं हैं: Opus और Sonnet की सीमाएं, और Max तथा Premium सीटों पर Fable का आवंटन जो आपकी साप्ताहिक सीमा के 50% तक हो सकता है। Pro और Standard सीटों पर, Fable प्लान की सीमाओं में शामिल नहीं है और पहले अनुरोध से ही यूसेज क्रेडिट्स पर बिल किया जाता है।

Claude for Teams और सीट-आधारित Enterprise पर, दस्तावेजीकृत संरचना प्रति-सीट अलाउंस की है जो पांच घंटे की रोलिंग विंडो और साप्ताहिक विंडो पर रीसेट होती है, जिसे Claude चैट और Cowork के साथ साझा किया जाता है, और इसका आकार सीट टियर (Standard या Premium) द्वारा निर्धारित होता है। वर्तमान यूसेज-आधारित Enterprise प्लान अलग तरह से काम करते हैं: इसमें कोई शामिल अलाउंस नहीं होता जिसे समाप्त किया जा सके, उपयोग API दरों पर बिल किया जाता है, और अधिकतम सीमा वह होती है जिसे एडमिन संगठन स्तर पर और व्यक्तिगत उपयोगकर्ताओं के लिए सेट करते हैं। सेल्स-असिस्टेड प्लान पर, स्पेंड लिमिट के कारण रुका हुआ उपयोग अगले बिलिंग पीरियड की शुरुआत में फिर से शुरू हो जाता है, जब तक कि कोई ओनर पहले सीमा न बढ़ा दे। सेल्फ-सर्व प्लान पर, प्रीपेड क्रेडिट बैलेंस खत्म होने पर भी उपयोग रुक जाता है, जब तक कि कोई ओनर और क्रेडिट न खरीदे। Pro और Max पर, संदेश में छपा रीसेट समय और आपके स्वयं के /usage बार ही विश्वसनीय आंकड़े हैं, न कि किसी ब्लॉग पोस्ट से कॉपी किया गया कोई आंकड़ा। यदि आप अभी भी टियर चुन रहे हैं, तो आपको किस Claude प्लान की आवश्यकता है यह तुलना करता है कि प्रत्येक प्लान क्या सीमित करता है।

/model के साथ मॉडल बदलने पर सेशन या साप्ताहिक सीमा रीसेट क्यों नहीं होती है

यह सबसे आम गलत कदम है, और डॉक्यूमेंटेशन इस बारे में स्पष्ट है: सेशन और साप्ताहिक सीमाएं सभी मॉडल्स के बीच साझा की जाती हैं, इसलिए मॉडल बदलने से एक्सेस रीसेट नहीं होता है। सेशन विंडो समाप्त होने के बाद छोटा मॉडल चुनने से केवल यह बदलता है कि कौन सा मॉडल उत्तर देगा। इससे यह नहीं बदलता कि कितनी अनुमति (allowance) शेष है, क्योंकि सेशन और साप्ताहिक अनुमति प्रति मॉडल नहीं होती है, इसलिए स्विच करने से कुछ भी रीसेट नहीं होता है।

इसके अपवाद मॉडल-फैमिली की सीमाएं हैं। यदि संदेश में You've hit your Opus limit या You've hit your Sonnet limit लिखा है, तो /model सही समाधान है। उस फैमिली से बाहर के किसी मॉडल पर स्विच करें और काम जारी रखें, क्योंकि केवल उसी फैमिली के अनुरोध ब्लॉक किए गए थे। Max और Premium सीट्स पर Fable की सीमा भी इसी तरह काम करती है: अपने प्लान के भीतर काम जारी रखने के लिए किसी अन्य मॉडल पर स्विच करें, या उपयोग क्रेडिट (usage credits) पर Fable का उपयोग जारी रखें। हालाँकि, Fable अन्य मॉडल्स की तुलना में साझा साप्ताहिक पूल का उपयोग तेजी से करता है, इसलिए Fable की सीमा के बाद स्विच करने से आप अपनी कुल साप्ताहिक सीमा से आगे नहीं निकल जाते हैं।

सीमा को बग मानना दूसरा गलत कदम है। रीइंस्टॉल करने या दोबारा ऑथेंटिकेट करने से कुछ नहीं बदलता है। अनुमति तब वापस आती है जब विंडो रीसेट होती है, जब आप फ्री लिमिट रीसेट का उपयोग करते हैं, या जब आप उपयोग क्रेडिट खरीदते हैं।

सब्सक्रिप्शन लिमिट तक पहुँचने पर क्या करें

  1. रिसेट होने का समय देखें। सेशन विंडो छोटी होती है। साप्ताहिक विंडो के लिए डेस्क पर बैठकर इंतजार करना व्यावहारिक नहीं है। Claude Code v2.1.234 या उसके बाद के वर्ज़न पर, /rate-limit-options रिसेट का इंतजार कर सकता है और बाधित कार्य को स्वचालित रूप से जारी रख सकता है।
  2. यदि यह Opus, Sonnet या Fable की लिमिट है, तो /model चलाएं और उस फैमिली से बाहर का कोई मॉडल चुनें।
  3. अपनी प्लान लिमिट, बार और उनके रिसेट होने का समय देखने के लिए /usage चलाएं। /cost उसी स्क्रीन के लिए एक एलियास (alias) है।
  4. claude.ai पर या Claude Desktop में Settings > Usage पर जाकर Resets सेक्शन देखें। पात्र प्लान्स को कभी-कभी मुफ्त लिमिट रिसेट का विकल्प दिया जाता है, और "Reset for free" पर क्लिक करने से आपकी पांच घंटे की सेशन लिमिट या साप्ताहिक लिमिट, जो भी ऑफर में शामिल हो, तुरंत पूरी तरह रिसेट हो जाती है। यह बटन टर्मिनल या IDE में Claude Code पर, या Claude Mobile पर उपलब्ध नहीं है, और प्रत्येक ऑफर की एक समय सीमा होती है।
  5. लिमिट से आगे काम जारी रखने के लिए /usage-credits चलाएं। Pro और Max प्लान पर यह आपकी बिलिंग सेटिंग्स खोलता है। Team और Enterprise प्लान पर यह आपके संगठन की उपयोग सेटिंग्स खोलता है, या यदि आपके पास बिलिंग एक्सेस नहीं है तो आपके एडमिन को अनुरोध भेजता है।
  6. यदि आप हर हफ्ते एक ही बाधा का सामना करते हैं, तो आपका प्लान आपके काम करने के तरीके के लिए सही नहीं है, और usage limit से बाहर निकलने के रास्ते पर हर बार रिसेट के समय सोचने के बजाय एक बार विचार करना बेहतर है।

/usage-credits के लिए /login के माध्यम से साइन-इन किए गए claude.ai सब्सक्रिप्शन की आवश्यकता होती है। यह API key ऑथेंटिकेशन के साथ उपलब्ध नहीं है, क्योंकि API key में विस्तार के लिए कोई प्लान अलाउंस नहीं होता है।

Usage credits का एक दुष्प्रभाव है जिसे पहले जानना जरूरी है। डिफ़ॉल्ट रूप से, Claude Code आपकी मुख्य बातचीत को तब तक एक घंटे का प्रॉम्प्ट कैश देता है जब तक आप सब्सक्रिप्शन की शामिल उपयोग सीमा के भीतर होते हैं, और क्रेडिट का उपयोग शुरू होते ही इसे घटाकर पांच मिनट कर देता है। इससे अधिक टर्न 'कोल्ड' शुरू होते हैं और Claude Code token usage उसी काम के लिए बढ़ जाता है। सब-एजेंट उस मुख्य-बातचीत बकेट से बाहर होते हैं, इसलिए उन्हें प्लान उपयोग के भीतर भी पांच मिनट ही मिलते हैं। promptCacheTtl सेटिंग या Claude Code v2.1.242 या उसके बाद के वर्ज़न पर CLAUDE_CODE_PROMPT_CACHE_TTL के साथ TTL को स्वयं चुनने से, क्रेडिट का उपयोग करते समय भी एक घंटे का लाइफटाइम बना रहता है।

वे संदेश जो usage limits जैसे दिखते हैं लेकिन वे नहीं हैं

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

  • Context या auto-compact की चेतावनी कोई usage limit नहीं है। /context एक लाइन प्रिंट करता है जैसे कि Context exceeds the 200k-token limit by 94k tokens, जिसके बाद वह कमांड होती है जो space खाली करती है, यह तब होता है जब conversation मॉडल की context window से बड़ी हो जाती है। Compacting पुरानी history का सारांश (summarize) बनाकर space खाली करता है, लेकिन यह मुफ्त नहीं है: /compact उस conversation को पढ़ता है जिसका वह सारांश बना रहा है, इसलिए एक बड़े context को compact करना स्वयं आपके plan के विरुद्ध एक बड़ा request होता है। जब आप निरंतरता (continuity) के बजाय एक नई शुरुआत चाहते हैं, तो /clear की कोई लागत नहीं होती।
  • Prompt is too long · automatic compaction failed: <the underlying error> का अर्थ है कि automatic compaction स्वयं विफल हो गया है, उस त्रुटि पर जिसका वह उल्लेख करता है। /compact उसी त्रुटि पर बार-बार विफल होता रहता है जब तक आप उसे हल नहीं कर लेते।
  • Credit balance is too low का अर्थ है कि आपके Console organization के prepaid credits समाप्त हो गए हैं, या Claude Code एक subscriber के requests को Console API key के माध्यम से भेज रहा है; /status दिखाता है कि कौन सा credential सक्रिय है। platform.claude.com/settings/billing पर credits जोड़ें, जो auto-reload की सुविधा भी प्रदान करता है।
  • API Error: Usage credits required for 1M context · run /usage-credits to turn them on (they take effect after you restart Claude Code), or /model to switch to standard context एक entitlement check है, न कि समाप्त हुआ कोटा। यदि आपने Opus 4.6 या Sonnet 4.6 का [1m] variant चुना है, तो [1m] suffix के बिना वाला variant चुनें, या CLAUDE_CODE_DISABLE_1M_CONTEXT=1 सेट करें। यदि यह conversation के बीच में दिखाई देता है क्योंकि context 200K tokens से अधिक हो गया है, तो Claude Code अपने आप standard limit के भीतर compact कर लेता है। Sonnet 5 और उसके बाद के वर्ज़न, Opus 4.7 और उसके बाद के वर्ज़न, Haiku 5.5 और Fable मॉडल native 1M window के साथ चलते हैं और उनमें हटाने के लिए कोई suffix नहीं होता; वह variable ही उन्हें 200K तक सीमित रखता है।

एक और त्रुटि API से आती है। 413 request_too_large एक single request पर size limit है, न कि rate limit।

API rate limits: 429 वास्तव में क्या गिनता है

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 का अनुरोध न करें। यह भी 429 rate_limit_error के रूप में आता है, लेकिन इसमें कोई retry-after header नहीं होता और error.details.error_code में enforced_spend_limit_reached होता है। इसे कोई retry loop ठीक नहीं कर सकता। Console में आपके द्वारा स्वयं सेट की गई कम spend limit अलग तरह से दिखाई देती है: requests HTTP 400 invalid_request_error लौटाते हैं, जिसका संदेश You have reached your specified API usage limits से शुरू होता है, और limit को बढ़ाने या हटाने से access बहाल हो जाता है।

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

Start, Build, Scale और Custom नामक Tiers वास्तविक संख्याएं निर्धारित करते हैं, जो आपके usage history और account standing के आधार पर स्वचालित रूप से असाइन की जाती हैं। नए organizations और जिनका usage history कम है, वे Evaluation tier में शुरू हो सकते हैं, जो मानक प्रकाशित limits से नीचे है, इसलिए पहला 429 तालिका के अनुमान से पहले आ सकता है। usage में अचानक वृद्धि acceleration limits को ट्रिगर करती है, जो आपके tier के भीतर रहने पर भी 429 लौटाती हैं, इसलिए traffic को धीरे-धीरे बढ़ाएं। प्रत्येक प्रकाशित आंकड़ा एक अधिकतम सीमा है: प्रलेखित limits अधिकतम अनुमत उपयोग हैं, न कि गारंटीकृत न्यूनतम। अधिक के लिए अनुरोध करने हेतु, Claude Console में Rate limits पेज पर "Request tier increase" का उपयोग करें।

429 को पढ़ना: retry-after, हेडर और SDK रिट्राय

प्रत्येक API त्रुटि एक ही लिफाफा (envelope) लौटाती है: एक नेस्टेड error ऑब्जेक्ट जिसमें प्रकार और संदेश होता है, साथ ही एक टॉप-लेवल request_id।

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

बाकी जानकारी हेडर्स में होती है।

  • retry-after उन सेकंड की संख्या है जितने समय तक आपको अनुरोध को पुनः प्रयास करने से पहले प्रतीक्षा करनी चाहिए। इससे पहले किए गए रिट्राय विफल हो जाएंगे। हर 429 में यह नहीं होता है, और spend-cap 429 में यह कभी नहीं होता है।
  • anthropic-ratelimit-requests-limit, anthropic-ratelimit-requests-remaining और anthropic-ratelimit-requests-reset आपके अनुरोध बजट का वर्णन करते हैं।
  • anthropic-ratelimit-input-tokens-* और anthropic-ratelimit-output-tokens-* ITPM और OTPM के लिए भी यही काम करते हैं, जिनमें समान limit, remaining और reset प्रत्यय (suffixes) होते हैं।
  • anthropic-ratelimit-tokens-* वर्तमान में प्रभावी सबसे प्रतिबंधात्मक सीमा के मान प्रदर्शित करता है।

रीसेट हेडर्स RFC 3339 टाइमस्टैम्प होते हैं। शेष टोकन हेडर्स को निकटतम हजार तक पूर्णांकित (rounded) किया जाता है, इसलिए उन्हें एक गेज के रूप में पढ़ें। फास्ट मोड का अपना पूल और अपने anthropic-fast-* हेडर्स होते हैं। किसी भी सफल कॉल से उन सभी को पढ़ें:

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'

प्रत्येक प्रतिक्रिया में एक अद्वितीय request-id हेडर भी होता है, जैसे कि req_018EeWyXxfu5pfWkrYcMdjWG। यह त्रुटि निकायों (error bodies) में request_id के रूप में और Python तथा TypeScript SDK प्रतिक्रियाओं पर _request_id के रूप में दिखाई देता है। सहायता टीम से संपर्क करते समय इसे उद्धृत (quote) करें।

बैकऑफ़ लूप लिखने से पहले यह जांच लें कि क्या आपको वास्तव में इसकी आवश्यकता है। आधिकारिक SDK स्वचालित रूप से क्षणिक विफलताओं (transient failures) को पुनः प्रयास करते हैं, जिनमें कनेक्शन त्रुटियां, दर सीमाएं (rate limits) और 5xx सर्वर त्रुटियां शामिल हैं। ये एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं, डिफ़ॉल्ट रूप से दो बार प्रयास करते हैं, और मौजूद होने पर retry-after हेडर का सम्मान करते हैं। प्रत्येक क्लाइंट इस व्यवहार को बदलने या अक्षम करने के लिए एक maximum-retries विकल्प स्वीकार करता है।

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

टेबल के बजाय अपनी सीमाएं स्वयं पढ़ें

सब्सक्रिप्शन पर, /usage वह स्क्रीन है जो मायने रखती है। यह आपके प्लान के उपयोग के बार और उन्हें खर्च करने वाले कारकों का विवरण दिखाती है, और d या w पिछले 24 घंटों और पिछले 7 दिनों के बीच स्विच करने की सुविधा देते हैं। दो सावधानियां ध्यान रखें। Session ब्लॉक API टोकन का उपयोग दिखाता है और यह API उपयोगकर्ताओं के लिए है, इसलिए सब्सक्राइबर इसकी डॉलर राशि को अनदेखा कर सकते हैं। ये संख्याएं उस मशीन के स्थानीय सत्र इतिहास से आती हैं, इसलिए किसी अन्य डिवाइस या claude.ai से किया गया उपयोग इसमें शामिल नहीं होता है।

API पक्ष पर, Claude Console में Usage पेज दो चार्ट दिखाता है, "Rate Limit - Input Tokens" और "Rate Limit - Output Tokens"। इनपुट चार्ट आपकी वर्तमान ITPM सीमा के मुकाबले प्रति मिनट अनकैश्ड इनपुट टोकन के प्रति घंटा अधिकतम उपयोग को प्लॉट करता है, साथ ही आपका कैश रेट भी दिखाता है, ताकि आप प्रोडक्शन में सीमा तक पहुँचने से पहले ही उसे देख सकें।

अपनी कॉन्फ़िगर की गई सीमाओं को प्रोग्रामेटिक रूप से पढ़ने के लिए:

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 क्रेडेंशियल्स की आवश्यकता होती है: एक Admin API key, org:admin स्कोप वाला एक OAuth token, या एक पर्सनल या सर्विस अकाउंट key जो किसी वर्कस्पेस तक सीमित न हो। Workspace API keys काम नहीं करती हैं। GET /v1/organizations/workspaces/{workspace_id}/rate_limits प्रत्येक वर्कस्पेस के लिए यही कार्य करता है। दोनों केवल पढ़ने (read-only) के लिए हैं: सीमा बदलने के लिए, Console में Rate limits पेज का उपयोग करें।

less का उपयोग करना, ताकि आप कम सीमाओं का सामना करें

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

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

जो काम context में बहुत सारा डेटा डालता है, उसे यह सबसे अधिक प्रभावित करता है: यदि आप live market data के मुकाबले stocks और options का विश्लेषण कर रहे हैं, तो केवल उस छोटे हिस्से को खींचना जिसकी हर प्रश्न को आवश्यकता है, पूरी quotes और chains की tables को पेस्ट करने की तुलना में बहुत सस्ता पड़ता है। किसी व्यक्ति के बजाय प्रोग्राम द्वारा संचालित काम को शुरू से ही API key पर होना चाहिए। वहां जाने से आपके भुगतान करने का तरीका और आपके मापे जाने का तरीका दोनों बदल जाते हैं, क्योंकि Claude API का कोई free tier नहीं है। Max और Team plans में आपके अपने apps और agents चलाने के लिए मासिक API credits शामिल होते हैं, एक बार जब आप Console organization को लिंक कर लेते हैं। ये credits Claude Code को कवर नहीं करते हैं और आपके प्लान की usage limits को नहीं बदलते हैं। VPS पर आपका पहला Claude API app key handling और retries को कवर करता है, और जब आप Claude Code को VPS पर tmux के अंदर चलाते हैं, तो एक लंबा agent run कनेक्शन टूटने पर भी सुरक्षित रहता है।

FAQ

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

क्योंकि session और weekly limits सभी models के बीच साझा की जाती हैं। यह allowance plan का हिस्सा है, न कि किसी विशेष model का, इसलिए /model केवल यह बदलता है कि कौन सा model उत्तर देगा, न कि यह कि कितनी allowance शेष है। इसके अपवाद model-family limits हैं: You've hit your Opus limit और You've hit your Sonnet limit केवल उसी family पर लागू होते हैं, और Max तथा Premium seats पर Fable limit केवल Fable को ही सीमित करती है। उन मामलों में, model बदलना ही निर्धारित समाधान है।

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

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

मैं अपनी 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 credentials (जैसे Admin API key) के साथ आपकी configured limits को दर्शाता है।

क्या मैं अपनी Claude plan limit तक पहुँचने के बाद काम जारी रख सकता हूँ?

कभी-कभी। Pro और Max पर सीमा से अधिक usage खरीदने के लिए, या Team और Enterprise पर admin से अनुरोध करने के लिए /usage-credits चलाएँ; इसके लिए /login के माध्यम से claude.ai login की आवश्यकता होती है और यह API key authentication के साथ उपलब्ध नहीं है। अन्यथा, reset समय की प्रतीक्षा करें, यदि Settings > Usage (claude.ai या Claude Desktop पर) कोई free limit reset विकल्प देता है तो उसका उपयोग करें, यदि यह Opus, Sonnet या Fable की limit थी तो model बदलें, या काम को API key पर ले जाएँ, जो window के बजाय प्रति मिनट के आधार पर meter की जाती है।