SSD Nodes Learn
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-07-24

Claude usage limits कशी सुधारावी?

Claude subscription आणि API 429 rate limits मधील फरक समजून घ्या. मर्यादा आल्यास model बदलूनही उपयोग होत नाही, त्यामुळे योग्य उपाय जाणून घ्या.

Claude च्या usage limits काय आहेत?

Claude च्या usage limits दोन वेगवेगळ्या प्रणालींमध्ये विभागल्या आहेत. प्रथम, तुम्हाला कोणत्या प्रणालीमुळे मर्यादा आली आहे हे ओळखणे आवश्यक आहे. Claude subscription (Pro, Max, Team, किंवा Enterprise) मध्ये तुम्हाला एक rolling usage allowance मिळते. हे सर्व models आणि Claude chat साठी सामायिक (shared) असते, त्यामुळे मर्यादा आल्यास You've hit your session limit · resets 3:45pm सारखा संदेश येतो. Claude API वेगळ्या गोष्टी मोजते: तुम्ही किती वेगाने requests आणि tokens पाठवता, जे प्रति मिनिट मोजले जातात. मर्यादा आल्यास rate_limit_error प्रकारचा HTTP 429 error येतो आणि retry-after header मध्ये किती सेकंद थांबायचे याची माहिती दिली जाते.

या दोन्ही मर्यादांचे उपाय पूर्णपणे वेगळे आहेत. Subscription limit ही एका ठराविक कालावधीतील (window) वापराशी संबंधित आहे, त्यामुळे तुम्हाला reset होण्याची वाट पाहावी लागते किंवा अधिक usage खरेदी करावे लागते. API rate limit ही तुमच्या सध्याच्या वेगाशी संबंधित आहे, आणि तुम्ही वेग कमी केल्यावर काही सेकंदात ती सुटते.

Plan allowances आणि rate-limit tier numbers वारंवार बदलतात. चुकीची संख्या देण्यापेक्षा कोणतीही संख्या न देणे अधिक चांगले आहे, म्हणून येथे कोणतीही संख्या दिलेली नाही. खाली दिलेल्या commands वापरून तुमची स्वतःची माहिती मिळवा.

तुम्ही कोणत्या मर्यादेपर्यंत पोहोचला आहात? नेमका संदेश वाचा

Claude Code मजकुरात सिस्टीमचे नाव दर्शवते. काहीही बदलण्यापूर्वी तुमच्या सिस्टीमशी त्याची तुलना करा.

  • 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 साठी आहे.
  • You've hit your Opus limit · resets 3:45pm ही subscription limit आहे जी फक्त 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 project साठी कॉन्फिगर केलेली मर्यादा ओलांडली आहे.
  • API Error: Server is temporarily limiting requests (not your usage limit) हा short-lived throttle आहे जो तुमच्या plan quota शी संबंधित नाही. Claude Code तो संदेश दाखवण्यापूर्वी backoff सह आपोआप retry करतो.

Subscription limits: session, weekly, and the Opus window

Subscription plan मध्ये वापरण्यासाठी ठराविक मर्यादा (allowance) असते. ही मर्यादा संपली की, संदेशात दिलेल्या reset time पर्यंत Claude Code पुढील requests ब्लॉक करते. या मर्यादेमुळे प्रामुख्याने दोन गोष्टींमुळे गोंधळ निर्माण होतो.

  • ही मर्यादा Claude chat सोबत सामायिक (shared) असते. claude.ai वरील कामासाठी आणि terminal वरील कामासाठी एकाच allowance चा वापर होतो. त्यामुळे chat मध्ये जास्त वेळ वापर केल्यास कोडिंगसाठीची वेळ कमी पडू शकते.
  • ही मर्यादा सर्व models साठी सामायिक असते. Opus limit वगळता, session आणि weekly limits मध्ये प्रत्येक model साठी वेगळी मर्यादा नसते.

Claude for Teams आणि Enterprise मध्ये, प्रत्येक seat साठी एक allowance असते. हे rolling five-hour window आणि weekly window वर reset होते. हे Claude chat आणि Cowork सोबत सामायिक असते आणि seat tier (Standard किंवा Premium) नुसार ठरवले जाते. Pro आणि Max मध्ये, संदेशात दिलेला reset time आणि तुमचे स्वतःचे /usage bars हेच अचूक असतात, ब्लॉग पोस्टमधील आकडेवारी नाही. जर तुम्ही अजून tier निवडला नसेल, तर तुम्हाला कोणता Claude plan हवा आहे यामध्ये प्रत्येक plan च्या मर्यादांची तुलना दिली आहे.

/model वापरून मॉडेल बदलल्यास प्रवेश (access) का परत मिळत नाही

ही सर्वात सामान्य चूक आहे आणि डॉक्युमेंटेशनमध्ये याबद्दल स्पष्टपणे सांगितले आहे: session आणि weekly limits सर्व मॉडेल्ससाठी सामायिक (shared) असतात, त्यामुळे मॉडेल बदलल्याने प्रवेश पुन्हा मिळत नाही. तुमचा session window संपल्यानंतर लहान मॉडेल निवडल्यास फक्त उत्तर देणारे मॉडेल बदलते. यामुळे शिल्लक असलेला allowance बदलत नाही, कारण allowance मॉडेलनुसार विभागलेला नसतो; त्यामुळे मॉडेल बदलल्याने कोणतीही मर्यादा सुटत नाही.

Opus limit हा याला अपवाद आहे, कारण ती मॉडेल-विशिष्ट मर्यादा आहे. जर संदेश You've hit your Opus limit असा असेल, तर /model हा योग्य उपाय आहे. दुसऱ्या मॉडेलवर स्विच करा आणि काम सुरू ठेवा, कारण फक्त Opus requests ब्लॉक करण्यात आल्या आहेत.

मर्यादेकडे (limit) एक bug म्हणून पाहणे ही दुसरी चूक आहे. Reinstalling किंवा re-authenticating केल्याने काहीही बदलत नाही. window reset झाल्यावर किंवा तुम्ही usage credits खरेदी केल्यावर allowance पुन्हा उपलब्ध होतो.

subscription limit आल्यास काय करावे

  1. reset time तपासा. session window अल्प असते. weekly window साठी तुम्हाला डेस्कवर बसून वाट पाहत राहण्याची गरज नाही.
  2. जर Opus limit आली असेल, तर /model चालवा आणि दुसरा model निवडा.
  3. तुमच्या plan limits, bars आणि ते कधी reset होतील हे पाहण्यासाठी /usage चालवा. /cost हा त्याच screen साठीचा alias आहे.
  4. मर्यादा ओलांडून काम सुरू ठेवण्यासाठी /usage-credits चालवा. Pro आणि Max मध्ये हे तुमचे billing settings उघडते. Team आणि Enterprise मध्ये हे तुमच्या organization चे usage settings उघडते, किंवा तुमच्याकडे billing access नसेल तर admins कडे request पाठवते.
  5. जर तुम्हाला दर आठवड्याला हीच अडचण येत असेल, तर तुमचा plan तुमच्या कामाच्या पद्धतीनुसार अपुरा आहे.

/usage-credits साठी /login द्वारे sign in केलेली claude.ai subscription आवश्यक आहे. API key authentication सह हे उपलब्ध नसते, कारण API key मध्ये वाढवण्यासाठी कोणतीही plan allowance नसते.

Usage credits चा एक महत्त्वाचा side effect आहे. subscription मध्ये prompt cache lifetime एक तास असते, परंतु एकदा का तुम्ही credits वापरण्यास सुरुवात केली की ते पाच मिनिटांवर येते; त्यामुळे अधिक turns 'cold' सुरू होतात आणि तितक्याच कामासाठी Claude Code token usage वाढतो.

Usage limits वाट्यासारखे दिसणारे परंतु प्रत्यक्षात नसलेले संदेश

Claude Code मधील चार त्रुटी (errors) usage limits म्हणून दाखवल्या जातात, परंतु त्या प्रत्यक्षात usage limits नाहीत.

  • context किंवा auto-compact चे warning म्हणजे usage limit नाही. जेव्हा conversation मॉडेलच्या context window पेक्षा मोठे होते, तेव्हा Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue. सारखी ओळ /context प्रिंट होते. जागा मोकळी करण्यासाठी जुना 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 आहे, quota संपल्यामुळे आलेली त्रुटी नाही. [1m] suffix नसलेला model variant निवडा किंवा CLAUDE_CODE_DISABLE_1M_CONTEXT=1 सेट करा.

आणखी एक त्रुटी 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 वापरासाठीची कमाल मासिक मर्यादा. एकदा का तुम्ही तुमच्या tier ची spend cap गाठली की, जोपर्यंत तुम्ही मर्यादा वाढवून मागत नाही तोपर्यंत API वापर थांबवला जातो. कोणताही retry loop यावर उपाय देऊ शकत नाही.

429 एरर कधी येईल हे चार घटक ठरवतात.

  • Limits model class नुसार असतात. त्या प्रत्येक model वर स्वतंत्रपणे लागू होतात, त्यामुळे तुम्ही एकाच वेळी वेगवेगळ्या models त्यांच्या संबंधित मर्यादांपर्यंत वापरू शकता. काही families एकाच bucket चा वापर करतात: Opus rate limit हे Claude Opus 4.8, Opus 4.7, Opus 4.6 आणि Opus 4.5 साठी एकत्रित असते, तर Claude Sonnet 5 ची स्वतःची मर्यादा असते.
  • Capacity सतत रिफिल होते. API token bucket algorithm वापरते, त्यामुळे capacity एका ठराविक वेळी reset होण्याऐवजी सतत replenished होत असते. 60 requests per minute ची मर्यादा असेल तर ती एका सेकंदाला एक request अशी लागू केली जाऊ शकते, त्यामुळे एकाच वेळी 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 मध्येही सवलत मिळते. Output च्या बाबतीत, उच्च max_tokens मुळे OTPM वर परिणाम होत नाही, कारण OTPM मध्ये फक्त प्रत्यक्षात तयार झालेले tokens मोजले जातात.
  • Limits organization level वर असतात. एखाद्या workspace साठी कमी मर्यादा दिली जाऊ शकते, आणि organization-wide limits नेहमी लागू होतात, जरी workspace limits ची बेरीज त्यापेक्षा जास्त असली तरीही. जर तुम्ही workspace वर कोणतीही मर्यादा ओव्हरराइड केली नसेल, तर ती organization कडून inherit केली जाते, ती unlimited नसते.

Start, Build, Scale आणि Custom अशी नावे असलेले tiers प्रत्यक्ष संख्या ठरवतात, जे तुमच्या usage history आणि account standing नुसार आपोआप नियुक्त केले जातात. नवीन organizations साठी मानक (standard) published limits पेक्षा कमी मर्यादा असू शकते, त्यामुळे पहिली 429 एरर टेबलमध्ये दिलेल्या अंदाजापेक्षा लवकर येऊ शकते. वापरामध्ये अचानक झालेली वाढ acceleration limits ट्रिगर करते, ज्यामुळे तुम्ही तुमच्या tier मध्ये असूनही 429 एरर येऊ शकते, म्हणून traffic हळूहळू वाढवा. प्रत्येक published figure ही एक ceiling आहे: documented limits ही कमाल परवानगी दिलेली मर्यादा आहे, ती खात्री दिलेली किमान मर्यादा (guaranteed minimums) नाही. अधिक मर्यादा हवी असल्यास, Claude Console मधील Limits page वरील "Request rate limit increase" कंट्रोल वापरा.

429: retry-after, headers आणि SDK retries वाचणे

प्रत्येक API error मध्ये एकच envelope परत मिळते: यामध्ये type आणि message असलेले एक nested error object असते, आणि एक 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 म्हणजे 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-* सध्या लागू असलेल्या सर्वात restrictive limit ची values दर्शवते.

Reset headers हे RFC 3339 timestamps असतात. Remaining token headers जवळच्या हजारामध्ये (nearest thousand) rounded असतात, त्यामुळे त्यांचा वापर फक्त अंदाज घेण्यासाठी (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 मध्ये एक unique 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) साठी automatic retry करतात. यामध्ये exponential backoff वापरले जाते. 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 वर खूप जास्त ट्रॅफिक येते, तेव्हा असे होऊ शकते. तुमच्या API key मुळे किंवा कोडमुळे हे घडत नाही. exponential backoff वापरून पुन्हा प्रयत्न करा (SDKs मध्ये 5xx responses साठी ही सुविधा आधीच असते) आणि जर समस्या सुटली नाही तर status.claude.com तपासा. 500 api_error ही अंतर्गत त्रुटी (internal error) आहे, ज्यासाठी तुम्हाला त्याच पद्धतीने पुन्हा प्रयत्न करावा लागेल. यापैकी कोणतीही त्रुटी rate limit नाही.

टेबलऐवजी तुमच्या स्वतःच्या मर्यादा तपासा

सबस्क्रिप्शनमध्ये, /usage ही महत्त्वाची स्क्रीन आहे. यामध्ये तुमच्या प्लॅनचा वापर (usage bars) आणि वापराचे तपशील दिसतात. तसेच, d किंवा w द्वारे तुम्ही गेल्या 24 तासांचा किंवा गेल्या 7 दिवसांचा डेटा पाहू शकता. दोन महत्त्वाच्या गोष्टी लक्षात घ्या. Session ब्लॉक API token चा वापर दर्शवतो आणि तो प्रामुख्याने API वापरकर्त्यांसाठी आहे, त्यामुळे सबस्क्राइबर्सनी त्यातील डॉलरची रक्कम दुर्लक्षित करावी. हे आकडे त्या मशीनवरील स्थानिक session history वरून येतात, त्यामुळे इतर डिव्हाइस किंवा claude.ai वरील वापर यामध्ये दिसणार नाही.

API च्या बाबतीत, Claude Console मधील Usage पेज दोन चार्ट्स दर्शवते: "Rate Limit - Input Tokens" आणि "Rate Limit - Output Tokens". इनपुट चार्ट तुमच्या सध्याच्या ITPM मर्यादेच्या तुलनेत दर मिनिटाला uncached इनपुट टोकन्सची तासाची कमाल मर्यादा (hourly maximum) दर्शवतो. त्यासोबत तुमचा 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 प्रत्येक workspace साठी हेच कार्य करते. दोन्ही read-only आहेत: मर्यादा बदलण्यासाठी, Console मधील Limits टॅब वापरा.

less चा वापर करा, जेणेकरून तुम्ही मर्यादांच्या बाहेर जाणार नाही

दोन्ही प्रणाली अंतर्गत एकच गोष्ट मोजतात, त्यामुळे हे पर्याय दोन्हीसाठी लागू होतात.

  • प्रत्येक turn साठी कमी tokens वापरा. सतत काम केल्यामुळे cache गरम राहते आणि असंबद्ध कामांमध्ये /clear केल्यास कोणताही खर्च येत नाही. Claude Code token usage मध्ये या सर्व पर्यायांची सविस्तर माहिती दिली आहे.
  • प्रयत्न (effort) कमी करा. याचे स्तर low, medium, high, xhigh आणि max असे आहेत. /effort मेनूमध्ये ultracode हा पर्याय देखील आहे, जो खर्च कमी करण्याऐवजी तो वाढवतो. केवळ मेकॅनिकल रीनेमिंगसाठी डीप रिझनिंग वापरण्यात काही अर्थ नाही.
  • 429 एरर आल्यावर concurrency कमी करा. CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY कमी करा आणि अनेक समांतर subagents वापरणे टाळा. /status देखील वापरा: एखादा विस्कळीत ANTHROPIC_API_KEY तुमच्या subscription ऐवजी low-tier key द्वारे requests पाठवू शकतो.
  • Non-interactive काम Message Batches API वर हलवा. हे मोठ्या प्रमाणात काम asynchronously करते. यामध्ये input आणि output tokens वर 50% सूट मिळते आणि त्याचे स्वतःचे rate limits असतात, ज्यामुळे रात्रीचे (nightly) जॉब तुमच्या सेशनमध्ये अडथळा ठरत नाहीत.

मानवाऐवजी प्रोग्रामद्वारे चालणारे Bursty काम सुरुवातीपासूनच API key वर चालवणे योग्य ठरते. Your first Claude API app on a VPS मध्ये key handling आणि retries बद्दल माहिती दिली आहे. तसेच, जर तुम्ही Claude Code running on a VPS inside tmux वापरले, तर कनेक्शन तुटले तरी लांब चालणारे agent run यशस्वीरित्या चालू राहते.

FAQ

मॉडेल बदलल्यामुळे माझी Claude usage limit का सुधरत नाही?

कारण session आणि weekly limits सर्व मॉडेल्ससाठी सामायिक (shared) असतात. ही मर्यादा तुमच्या plan साठी असते, मॉडेलसाठी नाही; त्यामुळे /model मुळे फक्त उत्तर देणारे मॉडेल बदलते, परंतु शिल्लक allowance बदलत नाही. You've hit your Opus limit हा एकमेव अपवाद आहे, जो फक्त Opus requests साठी लागू होतो. अशा वेळी मॉडेल बदलणे हा अधिकृत उपाय आहे.

429 rate_limit_error चा अर्थ काय आणि मी किती वेळ थांबायला हवे?

याचा अर्थ तुमच्या खात्याने त्या विशिष्ट model class साठी ठरवून दिलेली मर्यादा (rate limit) ओलांडली आहे: जसे की requests per minute, input tokens per minute, किंवा output tokens per minute. प्रतिसादामध्ये (response) retry-after हे header येते, ज्यामध्ये किती सेकंद थांबायचे याची माहिती असते; त्याआधी केलेले retries अयशस्वी ठरतात. अधिकृत SDKs मध्ये rate limits आणि 5xx errors साठी exponential backoff सह default द्वारे दोनदा retry करण्याची सोय असते, जे त्या header चे पालन करते. जर तुम्ही तुमच्या tier च्या मर्यादेत असताना 429 error येत असेल, तर याचा अर्थ अचानक वाढलेल्या requests मुळे 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 दर्शवते, आणि GET /v1/organizations/rate_limits Admin API key वापरून तुमच्या configured limits परत करते.

Claude plan limit संपल्यानंतर मी काम सुरू ठेवू शकतो का?

काही वेळा शक्य आहे. Pro आणि Max प्लॅनवर मर्यादा ओलांडल्यानंतर अधिक usage खरेदी करण्यासाठी किंवा Team आणि Enterprise प्लॅनवर admin कडून विनंती करण्यासाठी /usage-credits चालवा; यासाठी /login द्वारे claude.ai लॉगिन आवश्यक आहे आणि API key authentication असताना ही सुविधा उपलब्ध नसते. अन्यथा, reset time ची वाट पहा, जर ती Opus limit असेल तर मॉडेल बदला, किंवा तुमचे काम API key कडे वळवा, जे window ऐवजी per minute नुसार मोजमाप करते.

#claude#claude-code#ai#rate-limits#api