Claude usage limit संपल्यावर काय करावे?

Claude च्या वापरावर कोणत्या मर्यादा आहेत?

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

दोन्ही समस्यांवरील उपाय पूर्णपणे वेगळे आहेत. Subscription limit ही एखाद्या window मध्ये तुम्ही किती वापर केला यावर आधारित असते. त्यामुळे reset होईपर्यंत प्रतीक्षा करा किंवा अधिक usage खरेदी करा. API rate limit हा त्या क्षणी तुमचा वेग किती आहे यावर आधारित असतो. Requests हळू केल्यावर तो काही seconds मध्ये दूर होतो.

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

तुम्ही कोणती मर्यादा गाठली? अचूक संदेश वाचा

Claude Code छापत असलेल्या मजकुरात संबंधित system चे नाव स्पष्टपणे देते. कोणताही बदल करण्यापूर्वी तुमच्या संदेशाशी ते जुळते का ते तपासा.

• You've hit your session limit · resets 3:45pm ही subscription मर्यादा आहे. या window साठी तुमच्या plan ला मिळालेली rolling allowance संपली आहे.
• You've hit your weekly limit · resets Mon 12:00am ही त्याच system ची अधिक दीर्घ window साठी असलेली मर्यादा आहे.
• You've hit your Opus limit · resets 3:45pm ही केवळ Opus requests वर लागू होणारी subscription मर्यादा आहे. 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 साठी configure केलेली मर्यादा तुम्ही गाठली आहे. यापैकी कोणती मर्यादा लागू होते हे client authentication कसे करते यावर अवलंबून असते, कारण Bedrock किंवा Vertex client चे metering Anthropic organization ऐवजी तुमच्या cloud project च्या quota विरुद्ध केले जाते.
• API Error: Server is temporarily limiting requests (not your usage limit) ही तुमच्या plan quota शी संबंधित नसलेली, अल्पकाळाची throttle आहे. हा संदेश दाखवण्यापूर्वी Claude Code backoff सह आपोआप retry करते.

Subscription limits: session, weekly, and the Opus window

Subscription plan मध्ये rolling usage allowance समाविष्ट असतो. तो allowance पूर्ण झाल्यावर संदेशात दाखवलेल्या reset time पर्यंत Claude Code पुढील विनंत्या block करते. या allowance च्या दोन वैशिष्ट्यांमुळे सर्वाधिक गोंधळ होतो.

• हा allowance Claude chat सोबत shared असतो. claude.ai वर केलेल्या कामाचा वापर terminal मधील कामासाठी असलेल्या त्याच allowance मधून होतो. त्यामुळे chat मध्ये दुपारभर जास्त वापर केल्यास coding साठीची संध्याकाळची उपलब्धता कमी होते. त्या account ने sign in केलेल्या प्रत्येक surface मधून याच pool मधील वापर होतो. त्यामुळे Linux वर beta desktop app आणि Claude Code CLI हे दोघे मिळून एक allowance वापरतात; प्रत्येकी एक allowance नाही.
• हा allowance models मध्येही shared असतो. Session आणि weekly limits साठी प्रत्येक model ला स्वतंत्र budget नसतो. केवळ Opus limit याला अपवाद आहे.

Claude for Teams आणि Enterprise मध्ये documented रचना per-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 वापरून मॉडेल बदलल्याने प्रवेश का पुनर्स्थापित होत नाही

ही सर्वात सामान्य चुकीची कृती आहे आणि दस्तऐवजीकरणात याबाबत स्पष्ट सूचना आहे: session आणि weekly limits सर्व मॉडेलमध्ये सामायिक असतात. त्यामुळे मॉडेल बदलल्याने प्रवेश पुनर्स्थापित होत नाही. तुमची session window संपल्यानंतर smaller model निवडल्याने उत्तर देणारे मॉडेल बदलते. मात्र उपलब्ध allowance चे प्रमाण बदलत नाही, कारण allowance कधीही प्रत्येक मॉडेलसाठी स्वतंत्र ठेवलेले नसते. त्यामुळे मॉडेल बदलल्याने release करण्यासाठी काहीही उपलब्ध नसते.

याला Opus limit हा अपवाद आहे. ही प्रत्यक्षात model-specific ceiling आहे. संदेश You've hit your Opus limit असा असल्यास /model हा योग्य उपाय आहे. दुसऱ्या मॉडेलवर switch करून काम सुरू ठेवा, कारण केवळ Opus requests block केलेल्या असतात.

Limit ला bug समजणे ही दुसरी चुकीची कृती आहे. Reinstall किंवा re-authenticate केल्याने काहीही बदलत नाही. Window reset झाल्यावर किंवा usage credits खरेदी केल्यावर allowance पुन्हा उपलब्ध होते.

मर्यादा संपल्यावर काय करावे

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

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

Usage credits चा एक परिणाम आधी जाणून घेणे महत्त्वाचे आहे. Subscription वर prompt cache lifetime एक तास असते. Credits वापरणे सुरू केल्यावर ती पाच मिनिटांवर येते. त्यामुळे अधिक turns सुरुवातीपासून सुरू होतात आणि त्याच कामासाठी Claude Code token usage वाढतो.

वापर मर्यादेसारखे दिसणारे, पण प्रत्यक्षात वापर मर्यादा नसलेले संदेश

Claude Code मधील चार त्रुटी वापर मर्यादा म्हणून नोंदवल्या जातात; परंतु त्यापैकी एकही वापर मर्यादा नाही.

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

आणखी एक त्रुटी API कडून येते. 413 request_too_large म्हणजे एका request वरील आकार मर्यादा; ती 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 गाठल्यानंतर, तुम्ही higher limit मागितली नाही तर पुढील महिन्यापर्यंत API वापर थांबतो. कोणताही retry loop ही समस्या सोडवू शकत नाही.

429 कधी येतो हे चार यंत्रणा ठरवतात.

• Limits प्रत्येक model class साठी स्वतंत्र असतात. त्या प्रत्येक model वर स्वतंत्रपणे लागू होतात. त्यामुळे वेगवेगळे models त्यांच्या संबंधित limits पर्यंत एकाच वेळी वापरता येतात. काही families एकच bucket share करतात: 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 होण्याऐवजी सातत्याने replenishment होते. प्रति मिनिट 60 requests ची limit प्रत्यक्षात प्रति सेकंद एक request अशा प्रकारे लागू केली जाऊ शकते. त्यामुळे 60 requests एकाच वेळी पाठवल्या तरी त्या fail होऊ शकतात.
• बहुतेक 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 स्तरावर असतात. एखाद्या workspace साठी lower limit देऊ शकता. Workspace limits ची बेरीज अधिक असली तरी organization-wide limits नेहमी लागू होतात. Workspace वर override केलेली नसलेली limit unlimited राहत नाही; ती organization कडून inherited असते.

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

429 प्रतिसाद वाचा: retry-after, headers आणि SDK retries

प्रत्येक API त्रुटी समान envelope परत करते. त्यामध्ये type आणि message असलेला nested error object आणि शीर्ष-स्तरीय request_id असतो.

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

उर्वरित माहिती headers मध्ये असते.

• retry-after म्हणजे विनंती पुन्हा करण्यापूर्वी प्रतीक्षा करायच्या सेकंदांची संख्या. त्यापूर्वी केलेले 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 साठी हीच माहिती देतात. त्यांच्यात limit, remaining आणि reset हेच suffixes असतात.
• anthropic-ratelimit-tokens-* सध्या लागू असलेल्या सर्वाधिक कडक limit ची मूल्ये दाखवते.

Reset headers RFC 3339 timestamps असतात. Remaining token headers जवळच्या हजारापर्यंत round केलेले असतात. त्यामुळे त्यांना gauge म्हणून वाचा. Fast mode साठी स्वतंत्र pool आणि स्वतंत्र anthropic-fast-* headers असतात. यशस्वी 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 मध्ये अद्वितीय request-id header देखील असतो, उदाहरणार्थ req_018EeWyXxfu5pfWkrYcMdjWG. Error bodies मध्ये तो request_id म्हणून आणि Python व TypeScript SDK responses मध्ये _request_id म्हणून दिसतो. Support शी संपर्क साधताना त्याचा उल्लेख करा.

Backoff loop लिहिण्यापूर्वी त्याची खरोखर गरज आहे का ते तपासा. अधिकृत SDKs transient failures साठी आपोआप retry करतात. यामध्ये connection errors, rate limits आणि 5xx server errors यांचा समावेश होतो. ते exponential backoff वापरतात आणि 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 वर तात्पुरता अतिभार आहे. सर्व वापरकर्त्यांकडून API कडे मोठ्या प्रमाणात network traffic आल्यास असे होऊ शकते. यासाठी तुमची key किंवा code कारणीभूत नाही. Exponential backoff वापरून पुन्हा प्रयत्न करा. 5xx प्रतिसादांसाठी SDKs हे आधीच करतात. समस्या दूर होत नसेल, तर status.claude.com तपासा. 500 api_error हा internal error आहे. त्यासाठीही त्याच पद्धतीने पुन्हा प्रयत्न करा. यापैकी कोणताही प्रतिसाद rate limit नाही.

तुमच्या मर्यादा तक्त्याऐवजी थेट तपासा

सबस्क्रिप्शनमध्ये /usage हीच महत्त्वाची स्क्रीन आहे. त्यावर तुमच्या प्लॅनच्या वापराचे पट्टे आणि ते किती वापरले गेले याचे विभाजन दिसते. d किंवा w वापरून मागील 24 तास आणि मागील 7 दिवस यांमध्ये बदलता येते. दोन गोष्टी लक्षात ठेवा. Session विभागात API token चा वापर दाखवला जातो आणि तो API वापरकर्त्यांसाठी आहे. त्यामुळे subscribers त्यातील dollar figure दुर्लक्षित करू शकतात. हे आकडे त्या मशीनवरील स्थानिक session history मधून घेतले जातात. त्यामुळे दुसऱ्या device वरील किंवा claude.ai वरील वापर यात समाविष्ट होत नाही.

API च्या बाजूने, Claude Console मधील Usage पृष्ठावर "Rate Limit - Input Tokens" आणि "Rate Limit - Output Tokens" हे दोन charts दिसतात. Input chart मध्ये cache न केलेल्या input tokens ची प्रति मिनिट hourly maximum आणि तुमची सध्याची ITPM limit यांची तुलना दाखवली जाते. त्यासोबत cache rate देखील दिसतो. त्यामुळे production मध्ये limit ओलांडल्यानंतर कळण्याऐवजी ती limit जवळ येत आहे का हे monitor करता येते.

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 वापरा.

कमी वापर करा, त्यामुळे मर्यादा कमी लागू होतात

दोन्ही प्रणाली अंतर्गत समान गोष्ट मोजतात. त्यामुळे हे उपाय दोन्ही प्रणालींवर लागू होतात.

• प्रत्येक turn मध्ये कमी tokens खर्च करा. सलग कामाच्या सत्रांमुळे cache warm राहतो आणि असंबंधित कामांमध्ये /clear केल्याने कोणताही खर्च होत नाही. Claude Code चा token वापर या सर्व उपायांचे सविस्तर वर्णन करते.
• effort कमी करा. स्तर low, medium, high, xhigh आणि max आहेत. /effort menu मध्ये ultracode हाही पर्याय आहे. तो खर्च कमी करण्याऐवजी वाढवतो. यांत्रिक rename साठी deep reasoning वापरल्याने कोणताही फायदा होत नाही.
• 429 नंतर concurrency कमी करा. CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY कमी करा आणि अनेक parallel subagents टाळा. /status देखील चालवा: अनावधानाने राहिलेला ANTHROPIC_API_KEY requests तुमच्या subscription ऐवजी low-tier key मार्फत पाठवतो.
• non-interactive काम Message Batches API कडे हलवा. ही API मोठ्या प्रमाणातील काम asynchronous पद्धतीने चालवते. Input आणि output tokens वर 50% discount मिळतो आणि स्वतंत्र rate limits लागू होतात. त्यामुळे nightly job तुमच्या session शी स्पर्धा करणे थांबवते.

Context मध्ये मोठ्या प्रमाणात data भरावे लागणाऱ्या कामावर याचा परिणाम सर्वाधिक जाणवतो. उदाहरणार्थ, live market data विरुद्ध stocks आणि options चे विश्लेषण करताना, प्रत्येक प्रश्नासाठी आवश्यक असलेला मर्यादित data slice आणणे, quotes आणि chains च्या संपूर्ण tables paste करण्यापेक्षा खूप कमी खर्चिक असते. व्यक्तीऐवजी program चालवत असलेले bursty काम सुरुवातीपासून API key वर ठेवणे योग्य आहे. त्यामुळे metering प्रमाणेच payment पद्धतही बदलते, कारण Claude API मध्ये free tier नाही; signup वेळी मिळणाऱ्या लहान credit पलीकडे कोणतीही free tier उपलब्ध नाही. VPS वर तुमचे पहिले Claude API app key handling आणि retries यांचे वर्णन करते. तसेच, tmux च्या आत VPS वर Claude Code चालू ठेवले तर connection तुटल्यानंतरही दीर्घ agent run सुरू राहतो.

FAQ

मॉडेल बदलल्याने माझी Claude वापर मर्यादा का दूर होत नाही?

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

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

याचा अर्थ तुमच्या खात्याने त्या मॉडेल वर्गासाठी rate limit गाठली आहे: प्रति मिनिट विनंत्या, प्रति मिनिट input tokens किंवा प्रति मिनिट output tokens. प्रतिसादामध्ये retry-after header असतो. त्यात प्रतीक्षा करण्यासाठी आवश्यक सेकंद दिलेले असतात. त्यापूर्वी केलेले retries अयशस्वी होतात. अधिकृत SDKs rate limits आणि 5xx errors साठी exponential backoff वापरून आपोआप retry करतात. ते default ने दोनदा retry करतात आणि त्या header मधील सूचनेचे पालन करतात. तुमच्या tier च्या मर्यादांमध्ये असतानाही 429 मिळत असल्यास, अचानक वाढलेल्या वापरामुळे acceleration limit लागू झाल्याचे ते दर्शवते.

माझ्या Claude वापर मर्यादा आणि त्या पुन्हा कधी सुरू होतात हे कसे पाहू?

Claude Code मध्ये तुमच्या plan च्या मर्यादा, reset वेळा आणि वापराचे विभाजन पाहण्यासाठी /usage चालवा. /cost हा त्याचा alias आहे. मागील 24 तास आणि मागील 7 दिवस यांमध्ये बदलण्यासाठी d किंवा w वापरा. ही आकडेवारी स्थानिक session history मधून येते. त्यामुळे इतर devices आणि claude.ai वरील वापर त्यात समाविष्ट होत नाही. API वर Console तुमच्या rate limits चे charts दाखवते. तुमच्या configured limits पाहण्यासाठी Admin API key सह GET /v1/organizations/rate_limits वापरा.

माझ्या Claude plan ची मर्यादा गाठल्यानंतर मी काम सुरू ठेवू शकतो का?

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