Claude వినియోగ పరిమితి చేరితే ఏం చేయాలి?

Claude వినియోగ పరిమితులు ఏమిటి?

Claude వినియోగ పరిమితులు రెండు వేర్వేరు వ్యవస్థలుగా ఉంటాయి. ముందుగా ఏ వ్యవస్థ మిమ్మల్ని ఆపిందో గుర్తించాలి. Claude subscription (Pro, Max, Team లేదా Enterprise) models మధ్య, అలాగే Claude chat తో భాగస్వామ్యం అయ్యే rolling usage allowance ను ఇస్తుంది. ఆ పరిమితి చేరుకున్నప్పుడు You've hit your session limit · resets 3:45pm వంటి message తో మిమ్మల్ని ఆపుతుంది. Claude API వేరే విషయాన్ని కొలుస్తుంది: మీరు requests మరియు tokens ను నిమిషానికి ఎంత వేగంగా పంపుతున్నారో. పరిమితి చేరుకున్నప్పుడు ఇది rate_limit_error రకానికి చెందిన HTTP 429 error ను, అలాగే ఎంత seconds వేచి ఉండాలో తెలిపే retry-after header ను పంపుతుంది.

ఈ రెండు సమస్యలకు పరిష్కారాలు పరస్పరం సంబంధం లేనివి. Subscription limit అనేది ఒక window లో మీరు ఎంత వినియోగించారనే విషయానికి సంబంధించినది. అందువల్ల reset కోసం వేచి ఉండాలి లేదా మరింత usage కొనాలి. API rate limit అనేది ప్రస్తుత సమయంలో మీ వేగానికి సంబంధించినది. మీరు వేగాన్ని తగ్గించిన తర్వాత ఇది కొన్ని seconds లో తొలగిపోతుంది.

Plan allowances మరియు rate-limit tier numbers తరచుగా మారుతుంటాయి. అందువల్ల తప్పు number చూపించడం కంటే number చూపించకపోవడమే మంచిది. ఇక్కడ numbers ఇవ్వలేదు. మీ స్వంత వివరాలను దిగువ commands తో చూడండి.

మీరు ఏ పరిమితిని చేరుకున్నారు? ఖచ్చితమైన సందేశాన్ని చదవండి

Claude Code అది ప్రదర్శించే పాఠ్యంలో సంబంధిత వ్యవస్థను పేర్కొంటుంది. ఏదైనా మార్చే ముందు, మీకు కనిపించిన వ్యవస్థను సరిపోల్చండి.

• You've hit your session limit · resets 3:45pm subscription పరిమితి. ఈ window కోసం మీ plan కు కేటాయించిన rolling allowance పూర్తిగా వినియోగించబడింది.
• You've hit your weekly limit · resets Mon 12:00am అదే వ్యవస్థకు సంబంధించిన దీర్ఘ window పరిమితి.
• You've hit your Opus limit · resets 3:45pm Opus అభ్యర్థనలకు మాత్రమే వర్తించే 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 ఎలా authenticate అవుతుందనే దానిపై ఆధారపడి ఉంటుంది. ఎందుకంటే Bedrock లేదా Vertex client Anthropic organization quota కు బదులుగా మీ cloud project quota పై meter చేయబడుతుంది.
• API Error: Server is temporarily limiting requests (not your usage limit) మీ plan quota కు సంబంధం లేని, తక్కువకాలం ఉండే throttle. ఈ పంక్తిని చూపించే ముందు Claude Code backoff తో దీన్ని స్వయంచాలకంగా retry చేస్తుంది.

సబ్‌స్క్రిప్షన్ పరిమితులు: session, weekly మరియు Opus window

సబ్‌స్క్రిప్షన్ ప్లాన్‌లో rolling usage allowance ఉంటుంది. అది పూర్తిగా వినియోగించబడితే, సందేశంలో చూపిన reset time వరకు Claude Code తదుపరి అభ్యర్థనలను నిరోధిస్తుంది. ఈ allowance కు సంబంధించిన రెండు లక్షణాల వల్ల ఎక్కువగా గందరగోళం ఏర్పడుతుంది.

• ఇది Claude chat తో భాగస్వామ్యం చేయబడుతుంది. claude.aiలో మీరు చేసే పని terminalలో చేసే పనికి ఉన్న అదే allowance నుంచి వినియోగించబడుతుంది. అందువల్ల chatలో గడిపిన అధిక వినియోగం మీ coding సమయానికి మిగిలే allowance ను తగ్గిస్తుంది. మీరు ఆ accountతో sign in చేసే ప్రతి surface అదే pool నుంచి వినియోగిస్తుంది. కాబట్టి Linuxలో beta desktop app మరియు Claude Code CLI రెండూ కలిసి ఒకే allowance ను వినియోగిస్తాయి; ఒక్కొక్కటి వేర్వేరు allowance ను కాదు.
• ఇది models మధ్య కూడా భాగస్వామ్యం చేయబడుతుంది. Session మరియు weekly limits కు model-specific budget ఉండదు. Opus limit మాత్రం దీనికి ఉన్న ఏకైక మినహాయింపు.

Claude for Teams మరియు Enterpriseలో documented నిర్మాణం per-seat allowance ఆధారంగా ఉంటుంది. ఇది rolling five-hour window మరియు weekly window ప్రకారం reset అవుతుంది. ఇది Claude chat మరియు Coworkతో భాగస్వామ్యం చేయబడుతుంది. దాని పరిమాణం seat tier (Standard లేదా Premium) పై ఆధారపడి ఉంటుంది. Pro మరియు Maxలో సందేశంలో ముద్రించబడిన reset time మరియు మీ స్వంత /usage bars మాత్రమే విశ్వసించదగిన సంఖ్యలు. Blog post నుంచి కాపీ చేసిన సంఖ్యను ఆధారంగా తీసుకోవద్దు. మీరు ఇంకా tier ఎంచుకుంటున్నట్లయితే, మీకు ఏ Claude plan అవసరమో ప్రతి plan ఏ పరిమితులను నియంత్రిస్తుందో పోల్చి చూపుతుంది.

/model తో మోడల్ మార్చినా యాక్సెస్ ఎందుకు పునరుద్ధరించబడదు

ఇది అత్యంత సాధారణమైన తప్పు చర్య. దీనిపై documentation స్పష్టంగా ఉంది: session మరియు weekly limits అన్ని models కు ఉమ్మడిగా వర్తిస్తాయి. అందువల్ల models మార్చడం వల్ల access పునరుద్ధరించబడదు. session window వినియోగం పూర్తైన తర్వాత చిన్న model ను ఎంచుకుంటే, సమాధానం ఇచ్చే model మాత్రమే మారుతుంది. మిగిలి ఉన్న allowance మారదు. ఎందుకంటే allowance ఏ model కు విడిగా కేటాయించబడలేదు. కాబట్టి model మార్చడం వల్ల విడుదల చేయడానికి ఏమీ ఉండదు.

Opus limit దీనికి మినహాయింపు. ఇది నిజంగా model-specific ceiling. సందేశం You've hit your Opus limit గా ఉంటే, /model సరైన పరిష్కారం. మరొక model కు మారి పని కొనసాగించండి. ఎందుకంటే Opus requests మాత్రమే block చేయబడ్డాయి.

Limit ను bug గా భావించడం రెండవ తప్పు చర్య. Reinstall చేయడం లేదా మళ్లీ authenticate చేయడం వల్ల ఏ మార్పూ ఉండదు. Window reset అయినప్పుడు లేదా usage credits కొనుగోలు చేసినప్పుడు allowance తిరిగి అందుబాటులోకి వస్తుంది.

చందా పరిమితిని చేరుకున్నప్పుడు ఏమి చేయాలి

1. రీసెట్ సమయాన్ని చూడండి. Session window తక్కువ వ్యవధి ఉంటుంది. Weekly window కోసం desk వద్ద వేచి ఉండాల్సిన అవసరం లేదు.
2. అది Opus పరిమితి అయితే, /model ను run చేసి మరొక model ను ఎంచుకోండి.
3. మీ plan limits, మిగిలిన bars, అవి reset అయ్యే సమయాన్ని చూడటానికి /usage ను run చేయండి. అదే screen కు /cost alias గా పనిచేస్తుంది.
4. ceiling దాటిన తర్వాత కూడా పని కొనసాగించడానికి /usage-credits ను run చేయండి. Pro మరియు Max లో ఇది మీ billing settings ను తెరుస్తుంది. Team మరియు Enterprise లో ఇది మీ organization usage settings ను తెరుస్తుంది. మీకు billing access లేకపోతే admins కు request పంపుతుంది.
5. ప్రతి వారం అదే పరిమితిని చేరుకుంటే, మీ పని విధానానికి ఆ plan సరైన పరిమాణంలో లేదు. ప్రతి reset సమయంలో పరిశీలించడంకన్నా, usage limit నుంచి బయటపడే మార్గాలును ఒకసారి పరిశీలించడం మంచిది.

/usage-credits కు /login ద్వారా sign in చేసిన claude.ai subscription అవసరం. API key authentication తో ఇది అందుబాటులో ఉండదు, ఎందుకంటే API key కు పెంచగల plan allowance ఉండదు.

Usage credits కు ముందుగా తెలుసుకోవాల్సిన ఒక ప్రభావం ఉంది. Subscription పై prompt cache lifetime ఒక గంట ఉంటుంది. Credits ఉపయోగించడం ప్రారంభించిన వెంటనే అది ఐదు నిమిషాలకు తగ్గుతుంది. అందువల్ల ఎక్కువ turns cache లేకుండా ప్రారంభమవుతాయి. అదే పనికి Claude Code token usage పెరుగుతుంది.

వాడుక పరిమితుల్లా కనిపించే, కానీ అవి కాని సందేశాలు

నాలుగు Claude Code లోపాలు usage limits గా నివేదించబడతాయి. కానీ వాటిలో ఏదీ usage limit కాదు.

• Context లేదా auto-compact హెచ్చరిక usage limit కాదు. Conversation model యొక్క context window పరిమితిని దాటినప్పుడు /context, Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue. వంటి ఒక పంక్తిని ముద్రిస్తుంది. పాత చరిత్రను సంక్షిప్తం చేసి స్థలం ఖాళీ చేస్తుంది. మీ plan allowance పై ఎలాంటి ప్రభావం ఉండదు.
• Error during compaction: Conversation too long. Press esc twice to go up a few messages and try again. అంటే /compact విఫలమైందని అర్థం. అది రూపొందించాల్సిన 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 అనేది ఒకే 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 ను చేరుకున్న తర్వాత, మీరు ఎక్కువ limit కోరితే తప్ప API వినియోగం తదుపరి నెల వరకు నిలిచిపోతుంది. Retry loop దీనిని పరిష్కరించదు.

429 ఎప్పుడు వస్తుందో నాలుగు విధానాలు నిర్ణయిస్తాయి.

• 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 నిరంతరం refills అవుతుంది. API token bucket algorithm ను ఉపయోగిస్తుంది. అందువల్ల capacity ఒక నిర్దిష్ట సమయానికి reset కాకుండా నిరంతరం replenishes అవుతుంది. నిమిషానికి 60 requests limit ను సెకనుకు ఒక request గా అమలు చేయవచ్చు. కాబట్టి ఒకేసారి పంపిన 60 requests విఫలమవుతాయి.
• చాలా 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 వాస్తవంగా ఉత్పత్తి అయిన tokens ను మాత్రమే లెక్కిస్తుంది.
• Limits organization స్థాయిలో ఉంటాయి. ఒక workspace కు తక్కువ limit ఇవ్వవచ్చు. Workspace limits మొత్తం ఎక్కువగా ఉన్నా organization-wide limits ఎల్లప్పుడూ వర్తిస్తాయి. Workspace పై override చేయని limit organization నుంచి inherit అవుతుంది; అది unlimited గా పరిగణించబడదు.

Start, Build, Scale మరియు Custom అనే tiers వాస్తవ సంఖ్యలను నిర్ణయిస్తాయి. ఇవి మీ usage history మరియు account standing ఆధారంగా స్వయంచాలకంగా కేటాయించబడతాయి. కొత్త organizations standard published limits కంటే తక్కువ స్థాయి నుంచి ప్రారంభం కావచ్చు. అందువల్ల table అంచనా వేసినదానికంటే ముందుగానే మొదటి 429 రావచ్చు. Usage లో ఆకస్మిక పెరుగుదల acceleration limits ను trigger చేస్తుంది. మీరు ఇంకా మీ tier లోపల ఉన్నప్పటికీ ఇవి 429 ను తిరిగి ఇస్తాయి. కాబట్టి traffic ను క్రమంగా పెంచండి. ప్రచురించిన ప్రతి సంఖ్య ఒక ceiling మాత్రమే. Documented limits అనేవి అనుమతించబడిన గరిష్ఠ usage; అవి హామీ ఇచ్చిన కనిష్ఠ పరిమితులు కావు. మరింత limit కోరడానికి Claude Console లోని Limits page పై "Request rate limit increase" control ను ఉపయోగించండి.

429 ప్రతిస్పందనను చదవడం: retry-after, headers మరియు SDK retries

ప్రతి API లోపం ఒకే 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 విఫలమవుతాయి.
• 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 ఉంటాయి.
• ప్రస్తుతం అమల్లో ఉన్న అత్యంత పరిమితమైన limit విలువలను anthropic-ratelimit-tokens-* చూపిస్తుంది.

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 రాయడానికి ముందు అది నిజంగా అవసరమా అని పరిశీలించండి. Official SDKs connection errors, rate limits మరియు 5xx server errors వంటి తాత్కాలిక failures ను exponential backoff తో స్వయంచాలకంగా retry చేస్తాయి. ఇది default గా రెండుసార్లు జరుగుతుంది. retry-after header ఉన్నప్పుడు SDKs దాని విలువను పాటిస్తాయి. ఈ ప్రవర్తనను మార్చడానికి లేదా నిలిపివేయడానికి ప్రతి 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 తాత్కాలికంగా అధిక లోడ్‌లో ఉందని అర్థం. అన్ని వినియోగదారుల నుంచి అధిక network traffic వచ్చినప్పుడు ఇది సంభవించవచ్చు. దీనికి మీ key లేదా code కారణం కాదు. Exponential backoff తో మళ్లీ ప్రయత్నించండి. 5xx responses కోసం SDKs ఇప్పటికే ఇదే విధంగా retry చేస్తాయి. సమస్య తొలగకపోతే status.claude.com ను పరిశీలించండి. 500 api_error కూడా internal error. దానికీ ఇదే విధంగా retry చేయాలి. ఈ రెండింటిలో ఏదీ rate limit కాదు.

మీ పరిమితులను పట్టికకు బదులుగా స్వయంగా పరిశీలించండి

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, cache చేయని input tokens per minute యొక్క గంటవారీ గరిష్ఠాన్ని మీ ప్రస్తుత ITPM limitతో పోలుస్తుంది. దాని పక్కనే మీ cache rateను కూడా చూపిస్తుంది. అందువల్ల productionలో limitను తాకిన తర్వాత తెలుసుకోవడం కాకుండా, అది చేరువవుతున్నదా అని monitor చేయవచ్చు.

మీరు configure చేసిన 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 అవసరం. ప్రతి workspaceకు ఇదే పని చేయడానికి GET /v1/organizations/workspaces/{workspace_id}/rate_limits ఉపయోగించండి. రెండూ read-only. Limitను మార్చడానికి Consoleలోని Limits tabను ఉపయోగించండి.

తక్కువ ఉపయోగంతో పరిమితులను తక్కువగా ఎదుర్కోవడం

రెండు సిస్టమ్‌లు అంతర్గతంగా ఒకే విషయాన్ని లెక్కిస్తాయి. అందువల్ల ఈ నియంత్రణలు రెండింటిలోనూ పనిచేస్తాయి.

• ప్రతి turnలో తక్కువ tokens ఖర్చు చేయండి. నిరంతరంగా సాగించే పని cacheను warmగా ఉంచుతుంది. సంబంధం లేని పనుల మధ్య /clear చేయడం వల్ల ఎటువంటి ఖర్చు ఉండదు. Claude Code token usage లో ఈ నియంత్రణలన్నీ పూర్తిగా వివరించబడ్డాయి.
• ప్రయత్న స్థాయిని తగ్గించండి. స్థాయిలు 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 ద్వారా పంపిస్తుంది.
• ఇంటరాక్టివ్ కాని పనిని Message Batches APIకి మార్చండి. ఇది పెద్ద పరిమాణంలోని పనిని asynchronousగా నిర్వహిస్తుంది. Input మరియు output tokensపై 50% discount ఉంటుంది. దీనికి స్వంత rate limits ఉంటాయి. అందువల్ల nightly job మీ sessionతో పోటీ పడదు.

Contextలోకి ఎక్కువ dataను పోసే పనుల్లో ఈ ప్రభావం ఎక్కువగా కనిపిస్తుంది. మీరు live market data ఆధారంగా stocks మరియు optionsను విశ్లేషిస్తుంటే, మొత్తం quotes మరియు chains పట్టికలను paste చేయడం కంటే ప్రతి ప్రశ్నకు అవసరమైన పరిమిత dataను మాత్రమే తీసుకోవడం వల్ల ఖర్చు చాలా తక్కువగా ఉంటుంది. వ్యక్తి కాకుండా program నడిపించే bursty పనిని మొదటి నుంచే API keyపై అమలు చేయాలి. అక్కడికి మారితే మీరు ఎలా చెల్లిస్తారో, usage ఎలా లెక్కించబడుతుందో రెండూ మారుతాయి. ఎందుకంటే Claude APIలో free tier లేదు; signup సమయంలో ఇచ్చే చిన్న credit మాత్రమే ఉంటుంది. VPSపై మీ మొదటి Claude API app key నిర్వహణ మరియు retriesను వివరిస్తుంది. అలాగే tmuxలో VPSపై Claude Codeను నడుపుతూ ఉంటే connection తెగిపోయినా దీర్ఘకాల agent run కొనసాగుతుంది.

FAQ

మోడళ్లను మార్చడం వల్ల నా Claude వినియోగ పరిమితి ఎందుకు తొలగదు?

అన్ని మోడళ్లకు session మరియు weekly limits ఉమ్మడిగా వర్తిస్తాయి. Allowance ఒక model‌కు కాకుండా plan‌కు చెందుతుంది. అందువల్ల /model ఏ model సమాధానం ఇవ్వాలో మాత్రమే మారుస్తుంది; మిగిలిన allowance పరిమాణాన్ని మార్చదు. దీనికి ఒకే మినహాయింపు You've hit your Opus limit. ఇది Opus requests‌కు మాత్రమే వర్తిస్తుంది. ఆ సందర్భంలో model మార్చడం documentation‌లో సూచించిన పరిష్కారం.

429 rate_limit_error అంటే ఏమిటి? నేను ఎంతసేపు వేచి ఉండాలి?

మీ account ఆ model class‌కు సంబంధించిన rate limit‌ను చేరిందని దీని అర్థం. ఈ పరిమితి requests per minute, input tokens per minute లేదా output tokens per minute కావచ్చు. Response‌లో వేచి ఉండాల్సిన seconds‌ను చూపించే retry-after header ఉంటుంది. అంతకుముందే retry చేస్తే అది విఫలమవుతుంది. Official SDKs rate limits మరియు 5xx errors కోసం exponential backoff‌తో స్వయంచాలకంగా retry చేస్తాయి. Default‌గా ఇవి రెండుసార్లు retry చేస్తాయి మరియు ఆ header‌ను గౌరవిస్తాయి. మీ tier limits‌లోనే ఉన్నప్పటికీ 429 వస్తే, అకస్మాత్తుగా పెరిగిన request రేటు వల్ల acceleration limit వర్తిస్తోందని అర్థం.

నా Claude వినియోగ పరిమితులు మరియు అవి reset అయ్యే సమయాన్ని ఎలా చూడాలి?

Claude Code‌లో మీ plan bars, reset times మరియు usage breakdown చూడటానికి /usage అమలు చేయండి. /cost ఒక alias. గత 24 గంటలు మరియు గత 7 రోజుల మధ్య మారడానికి d లేదా w ఉపయోగించండి. ఈ గణాంకాలు local session history నుంచి వస్తాయి. అందువల్ల ఇతర devices మరియు claude.ai నుంచి జరిగిన వినియోగం ఇందులో కనిపించదు. APIలో Console మీ rate limits‌ను charts‌లో చూపిస్తుంది. Admin API keyతో GET /v1/organizations/rate_limits అమలు చేస్తే configured limits తిరిగి వస్తాయి.

నా Claude plan limit‌ను చేరుకున్న తర్వాత కూడా పని కొనసాగించవచ్చా?

కొన్ని సందర్భాల్లో సాధ్యమే. Pro మరియు Maxలో ceiling దాటి usage కొనడానికి, లేదా Team మరియు Enterpriseలో admin నుంచి usage కోరడానికి /usage-credits అమలు చేయండి. దీని కోసం /login ద్వారా claude.ai login అవసరం. API key authentication‌తో ఇది అందుబాటులో ఉండదు. లేకపోతే reset time వరకు వేచి ఉండండి. అది Opus limit అయితే model మార్చండి. మరో మార్గంగా పనిని API keyకు మార్చవచ్చు. ఇందులో పరిమితి ప్రతి window‌కి కాకుండా ప్రతి minute‌కు లెక్కించబడుతుంది.