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 के साथ रोकता है, जिसमें बताया जाता है कि कितने सेकंड प्रतीक्षा करनी है।

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

Plan allowances और rate-limit tier की संख्या अक्सर बदलती रहती है, और गलत संख्या होने से बेहतर है कि कोई संख्या न दी जाए, इसलिए यहाँ कोई भी संख्या नहीं दी गई है। नीचे दिए गए 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 अनुरोधों पर लागू होती है। यह एकमात्र स्थिति है जहाँ मॉडल बदलना मददगार होता है।
• 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) करता है।

Subscription limits: session, weekly, और Opus window

एक subscription plan में rolling usage allowance शामिल होता है। जब यह समाप्त हो जाता है, तो Claude Code संदेश में दिखाए गए reset समय तक आगे के requests को ब्लॉक कर देता है। उस allowance की दो विशेषताएं सबसे अधिक भ्रम पैदा करती हैं।

• यह Claude chat के साथ साझा किया जाता है। claude.ai पर आप जो काम करते हैं, वह terminal में किए गए काम के समान allowance से ही लिया जाता है, इसलिए chat में बिताई गई एक भारी दोपहर आपकी कोडिंग की शाम को छोटा कर देती है। जिस भी surface पर आप उस account से sign in करते हैं, वह एक ही pool से उपयोग होता है, इसलिए Linux पर beta desktop app और Claude Code CLI दोनों एक ही allowance का उपयोग करते हैं, न कि अलग-अलग।
• यह models के बीच साझा किया जाता है। Session और weekly limits में प्रति-model कोई बजट नहीं होता है, केवल Opus limit इसका अपवाद है।

Claude for Teams और Enterprise पर, प्रलेखित संरचना प्रति-seat allowance है जो पांच घंटे की rolling window और एक साप्ताहिक window पर reset होती है, Claude chat और Cowork के साथ साझा की जाती है, और seat tier (Standard या Premium) के आधार पर निर्धारित होती है। Pro और Max पर, संदेश में छपा reset समय और आपके स्वयं के /usage bars ही विश्वसनीय आंकड़े हैं, न कि किसी ब्लॉग पोस्ट से कॉपी की गई संख्या। यदि आप अभी भी एक tier चुन रहे हैं, तो आपको किस Claude plan की आवश्यकता है यह तुलना करता है कि प्रत्येक plan क्या सीमित करता है।

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

यह सबसे आम गलत कदम है, और documentation इस बारे में स्पष्ट है: session और weekly limits सभी models के बीच साझा की जाती हैं, इसलिए models बदलने से एक्सेस वापस नहीं मिलता। session window समाप्त होने के बाद छोटा model चुनने से केवल यह बदलता है कि कौन सा model जवाब देगा। इससे यह नहीं बदलता कि कितनी allowance बची है, क्योंकि allowance कभी भी प्रति-मॉडल नहीं होती थी, इसलिए switch करने से कुछ भी release नहीं होता।

इसका अपवाद Opus limit है, जो वास्तव में एक मॉडल-विशिष्ट सीमा है। यदि संदेश You've hit your Opus limit दिखाता है, तो /model सही समाधान है। किसी अन्य model पर switch करें और काम जारी रखें, क्योंकि केवल Opus requests को ही ब्लॉक किया गया था।

limit को bug मानना दूसरा गलत कदम है। Reinstall करने या फिर से authenticate करने से कुछ नहीं बदलता। allowance तब वापस आती है जब window reset होती है, या जब आप usage credits खरीदते हैं।

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

1. रिसेट होने का समय देखें। सेशन विंडो छोटी होती है। साप्ताहिक विंडो का इंतज़ार डेस्क पर बैठकर करना व्यावहारिक नहीं है।
2. यदि यह Opus लिमिट है, तो /model चलाएँ और कोई दूसरा मॉडल चुनें।
3. अपनी प्लान लिमिट, बार और उनके रिसेट होने का समय देखने के लिए /usage चलाएँ। /cost उसी स्क्रीन के लिए एक alias है।
4. लिमिट से आगे काम जारी रखने के लिए /usage-credits चलाएँ। Pro और Max प्लान पर यह आपकी बिलिंग सेटिंग्स खोलता है। Team और Enterprise प्लान पर यह आपके संगठन की उपयोग सेटिंग्स खोलता है, या यदि आपके पास बिलिंग एक्सेस नहीं है तो आपके एडमिन को अनुरोध भेजता है।
5. यदि आप हर हफ्ते एक ही सीमा पर पहुँच रहे हैं, तो आपका प्लान आपके काम करने के तरीके के लिए सही नहीं है, और usage limit से बाहर निकलने के तरीके पर हर बार रिसेट के समय सोचने के बजाय एक बार विचार करना बेहतर है।

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

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

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

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

• context या auto-compact की चेतावनी usage limit नहीं है। /context एक लाइन प्रिंट करता है जैसे कि Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue., जब conversation मॉडल की context window से बड़ी हो जाती है। जगह खाली करने के लिए पुराने इतिहास का सारांश (summarize) बनाया जाता है, और आपके 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 समाप्त हो गए हैं। 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 है, न कि समाप्त हुआ कोटा। [1m] suffix के बिना मॉडल variant चुनें, या CLAUDE_CODE_DISABLE_1M_CONTEXT=1 सेट करें।

एक और त्रुटि API से आती है। 413 request_too_large एक सिंगल 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 का अनुरोध न करें। कोई भी retry loop इसे हल नहीं कर सकता।

चार तंत्र यह तय करते हैं कि 429 error कब आता है।

• 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 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 है। इसलिए, Caching छूट के साथ-साथ rate-limit के लिए अतिरिक्त headroom भी प्रदान करती है। output side पर, एक उच्च max_tokens OTPM के विरुद्ध नहीं गिना जाता है, क्योंकि OTPM केवल उन tokens को गिनता है जो वास्तव में generate हुए हैं।
• Limits organization स्तर पर होती हैं। एक workspace को कम limit दी जा सकती है, और organization-wide limits हमेशा लागू होती हैं, भले ही workspace limits का योग उससे अधिक हो। जिस limit को आपने workspace पर override नहीं किया है, वह organization से विरासत में मिलती है, न कि उसे unlimited छोड़ दिया जाता है।

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

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

हर API एरर एक ही एनवेलप लौटाता है: एक नेस्टेड error ऑब्जेक्ट जिसमें टाइप और मैसेज होता है, साथ ही एक टॉप-लेवल request_id।

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

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

• retry-after वह सेकंड की संख्या है जिसे आपको रिक्वेस्ट दोबारा भेजने से पहले प्रतीक्षा करनी चाहिए। इससे पहले की गई रिट्राय विफल हो जाएंगी।
• 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 सफिक्स होते हैं।
• anthropic-ratelimit-tokens-* वर्तमान में प्रभावी सबसे सख्त लिमिट के मान प्रदर्शित करता है।

रिसेट हेडर्स RFC 3339 टाइमस्टैम्प होते हैं। रिमेनिंग टोकन हेडर्स को निकटतम हजार तक राउंड किया जाता है, इसलिए उन्हें एक गेज (gauge) के रूप में पढ़ें। फास्ट मोड का अपना पूल और अपने 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। यह एरर बॉडी में request_id के रूप में और Python तथा TypeScript SDK रिस्पॉन्स पर _request_id के रूप में दिखाई देता है। सपोर्ट से संपर्क करते समय इसे कोट (quote) करें।

बैकऑफ लूप लिखने से पहले जांच लें कि क्या आपको वास्तव में इसकी आवश्यकता है। आधिकारिक SDKs स्वचालित रूप से ट्रांजिएंट विफलताओं को रिट्राय करते हैं, जिसमें कनेक्शन एरर, रेट लिमिट और 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 key की आवश्यकता होती है, और GET /v1/organizations/workspaces/{workspace_id}/rate_limits प्रत्येक वर्कस्पेस के लिए यही कार्य करता है। दोनों केवल पढ़ने (read-only) के लिए हैं: लिमिट बदलने के लिए, Console में Limits टैब का उपयोग करें।

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

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

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

जो कार्य डेटा को कॉन्टेक्स्ट में डालते हैं, उन्हें यह सबसे अधिक प्रभावित करता है: यदि आप analyzing stocks and options against live market data कर रहे हैं, तो प्रत्येक प्रश्न के लिए आवश्यक सीमित डेटा निकालने की लागत, पूरी टेबल पेस्ट करने की तुलना में बहुत कम होती है। किसी व्यक्ति के बजाय प्रोग्राम द्वारा संचालित कार्यों को शुरू से ही API key पर रखना चाहिए। वहां जाने से आपके भुगतान और मीटरिंग का तरीका बदल जाता है, क्योंकि the Claude API has no free tier साइनअप पर दिए गए छोटे क्रेडिट के अलावा और कुछ नहीं है। Your first Claude API app on a VPS की हैंडलिंग और retries को कवर करता है, और जब आप Claude Code running on a VPS inside tmux रखते हैं, तो एक लंबा एजेंट रन कनेक्शन टूटने पर भी सुरक्षित रहता है।

FAQ

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

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

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

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

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