Claude usage limits மற்றும் പരിஹாரங்கள்

Claude-ன் usage limits என்ன?

Claude-ன் usage limits இரண்டு தனித்தனி அமைப்புகளைக் (systems) கொண்டவை. முதலில் எந்த அமைப்பு உங்கள் பயன்பாட்டைக் கட்டுப்படுத்துகிறது என்பதைக் கண்டறிய வேண்டும். 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 அனுப்புகிறீர்கள் என்பதைக் கணக்கிடுகிறது (per minute). இது rate_limit_error வகை கொண்ட HTTP 429 error மற்றும் எத்தனை வினாடிகள் காத்திருக்க வேண்டும் என்பதைக் கூறும் retry-after header மூலம் உங்களைத் தடுக்கும்.

இவ்விரண்டுக்கும் இடையிலான தீர்வுகளுக்குத் தொடர்பில்லை. Subscription limit என்பது ஒரு குறிப்பிட்ட window காலத்திற்குள் நீங்கள் எவ்வளவு பயன்படுத்தினீர்கள் என்பதைக் குறிக்கிறது; எனவே reset ஆகும் வரை காத்திருக்க வேண்டும் அல்லது கூடுதல் usage வாங்க வேண்டும். API rate limit என்பது உங்கள் தற்போதைய வேகத்தைக் குறிக்கிறது; நீங்கள் வேகத்தைக் குறைத்தவுடன் சில வினாடிகளில் இது சரியாகிவிடும்.

Plan allowances மற்றும் rate-limit tier எண்கள் அடிக்கடி மாறக்கூடியவை. தவறான எண்ணைக் குறிப்பிடுவதை விட எதையும் குறிப்பிடாமல் இருப்பதே சிறந்தது, எனவே அவை இங்கே அச்சிடப்படவில்லை. கீழே உள்ள commands மூலம் உங்கள் சொந்த அளவுகளைப் பார்த்துக் கொள்ளலாம்.

எந்த limit-ஐ எட்டியுள்ளீர்கள்? சரியான message-ஐப் படிக்கவும்

Claude Code, அது அச்சிடும் text-இல் system-ஐக் குறிப்பிடும். எதையும் மாற்றுவதற்கு முன், உங்கள் message-ஐச் சரிபார்க்கவும்.

• 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-க்கான அதே system ஆகும்.
• You've hit your Opus limit · resets 3:45pm என்பது Opus requests-களுக்கு மட்டுமே பொருந்தும் subscription limit ஆகும். இந்தத் தடையைத் தவிர்க்க 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-க்கான limit-ஐ நீங்கள் எட்டியுள்ளீர்கள்.
• API Error: Server is temporarily limiting requests (not your usage limit) என்பது உங்கள் plan quota-வுடன் தொடர்பில்லாத குறுகிய கால throttle ஆகும். Claude Code அந்த message-ஐக் காட்டுவதற்கு முன், backoff முறையைப் பயன்படுத்தி தானாகவே மீண்டும் முயற்சிக்கும் (retry).

Subscription limits: session, weekly, and the Opus window

ஒரு subscription plan தொடர்ச்சியான usage allowance-ஐக் கொண்டுள்ளது. இந்த allowance தீர்ந்துவிட்டால், செய்தியில் காட்டப்படும் reset time வரும் வரை Claude Code அடுத்தடுத்த requests-ஐத் தடுக்கும். அந்த allowance-ன் இரண்டு பண்புகள் குழப்பத்தை ஏற்படுத்துகின்றன.

• இது Claude chat-உடன் பகிரப்படுகிறது. claude.ai-இல் நீங்கள் செய்யும் வேலைகள் terminal-இல் செய்யும் வேலைகளுக்குப் பயன்படுத்தப்படும் அதே allowance-லிருந்து எடுக்கப்படுகின்றன. எனவே, chat-இல் அதிக நேரம் செலவழிப்பது உங்கள் coding evening-ஐக் குறைக்கும்.
• இது models-களுக்கு இடையே பகிரப்படுகிறது. Opus limit தவிர, மற்ற session மற்றும் weekly limits-களுக்குத் தனித்தனி model budget கிடையாது.

Claude for Teams மற்றும் Enterprise பதிப்புகளில், இது ஒரு per-seat allowance ஆகும். இது rolling five-hour window மற்றும் weekly window அடிப்படையில் reset ஆகும். இது Claude chat மற்றும் Cowork ஆகியவற்றுடன் பகிரப்படுகிறது. இது seat tier (Standard அல்லது Premium) அடிப்படையில் தீர்மானிக்கப்படுகிறது. Pro மற்றும் Max பதிப்புகளில், செய்தியில் printed செய்யப்பட்ட reset time மற்றும் உங்கள் /usage bars ஆகியவையே சரியான அளவீடுகள்; blog post-லிருந்து எடுக்கப்பட்ட எண்களைப் பயன்படுத்த வேண்டாம். நீங்கள் இன்னும் ஒரு tier-ஐத் தேர்ந்தெடுக்கவில்லை என்றால், எந்த Claude plan உங்களுக்குத் தேவை என்பதைப் பார்த்துத் தீர்மானிக்கலாம்.

/model மூலம் model-ஐ மாற்றுவதால் ஏன் access மீண்டும் கிடைக்கவில்லை

இது மிகவும் பொதுவான தவறான செயலாகும். இது குறித்த தெளிவான விளக்கம் documentation-இல் உள்ளது: session மற்றும் weekly limits ஆகியவை அனைத்து models-களுக்கும் பொதுவானவை. எனவே, model-ஐ மாற்றுவதால் access மீண்டும் கிடைக்காது. உங்கள் session window முடிந்துவிட்ட நிலையில், ஒரு சிறிய model-ஐத் தேர்ந்தெடுப்பது, எந்த model பதிலளிக்கும் என்பதை மட்டுமே மாற்றும். இது மீதமுள்ள allowance அளவை மாற்றாது; ஏனெனில் allowance என்பது model-க்குத் தனித்தனியாகக் கணக்கிடப்படுவதில்லை. எனவே, model-ஐ மாற்றுவதால் எந்தக் கட்டுப்பாடும் நீக்கப்படாது.

Opus limit மட்டுமே இதற்கு விதிவிலக்கு; இது ஒரு model-க்கு மட்டுமே உரிய ceiling ஆகும். ஒருவேளை message You've hit your Opus limit என்று இருந்தால், /model என்பது சரியான தீர்வாகும். மற்றுமொரு 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. ceiling தாண்டி தொடர்ந்து வேலை செய்ய /usage-credits ஐ இயக்கவும். Pro மற்றும் Max plans-இல் இது உங்கள் billing settings-ஐத் திறக்கும். Team மற்றும் Enterprise plans-இல் இது உங்கள் organization-ன் usage settings-ஐத் திறக்கும், அல்லது உங்களுக்கு billing access இல்லையென்றால் உங்கள் admins-களுக்கு ஒரு request அனுப்பும்.
5. ஒவ்வொரு வாரமும் இதே தடையை நீங்கள் சந்தித்தால், உங்கள் வேலை முறைக்கு அந்த plan சரியான அளவு இல்லை என்று அர்த்தம்.

/usage-credits இயங்குவதற்கு /login மூலம் sign in செய்யப்பட்ட claude.ai subscription தேவை. API key authentication மூலம் இது இயங்காது, ஏனெனில் API key-இல் விரிவாக்க (extend)த் தேவையான plan allowance இருக்காது.

Usage credits-இல் முதலில் தெரிந்து கொள்ள வேண்டிய ஒரு side effect உள்ளது. Subscription முறையில் prompt cache lifetime ஒரு மணிநேரம் ஆகும், ஆனால் நீங்கள் credits-ஐப் பயன்படுத்தத் தொடங்கினால் அது ஐந்து நிமிடங்களாகக் குறையும். இதனால் அதிக turns cold-ஆகத் தொடங்கும், இதனால் அதே வேலையைச் செய்ய Claude Code token usage அதிகரிக்கும்.

Usage limits போன்ற தோற்றமளிக்கும் ஆனால் அவை அல்லாத செய்திகள்

Claude Code-இல் நான்கு பிழைகள் usage limits ලෙසக் காட்டப்படுகின்றன, ஆனால் அவை usage limits அல்ல.

• context அல்லது auto-compact எச்சரிக்கை என்பது usage limit அல்ல. உரையாடல் model-ன் 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 தோல்வியடைவதைக் குறிக்கிறது, ஏனெனில் 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 error எதைக் கணக்கிடுகிறது

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-ஐ நீங்கள் எட்டும்போது, நீங்கள் அதிக limit கோராதவரை அடுத்த மாதம் வரை API usage நிறுத்தப்படும். எந்த ஒரு retry loop-ஆலும் இதைச் சரிசெய்ய முடியாது.

429 error எப்போது வரும் என்பதை நான்கு காரணிகள் தீர்மானிக்கின்றன.

• Limits are per 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 refills continuously. API ஒரு token bucket algorithm-ஐப் பயன்படுத்துகிறது. எனவே, ஒரு குறிப்பிட்ட நேரத்தில் reset ஆவதற்குப் பதிலாக, capacity தொடர்ந்து நிரப்பப்படும். நிமிடத்திற்கு 60 requests என்ற limit இருந்தால், அது ஒரு வினாடிக்கு ஒரு request என்ற முறையில் அமையும். எனவே, ஒரே நேரத்தில் 60 requests அனுப்பப்பட்டால் அவை fail ஆகும்.
• Only uncached input counts toward ITPM on most models. input_tokens மற்றும் cache_creation_input_tokens கணக்கிடப்படும். பெரும்பாலான Claude models-களில் cache_read_input_tokens கணக்கிடப்படாது; Claude Haiku 3.5 இதற்கு விதிவிலக்காகும். எனவே, caching பயன்படுத்துவது rate-limit headroom மற்றும் தள்ளுபடி ஆகிய இரண்டையும் வழங்கும். Output பக்கத்தில், அதிக max_tokens இருப்பது OTPM-ஐப் பாதிக்காது, ஏனெனில் OTPM உண்மையில் உருவாக்கப்படும் tokens-களை மட்டுமே கணக்கிடுகிறது.
• Limits live at the organization level. ஒரு workspace-க்குக் குறைந்த limit வழங்கப்படலாம். organization-wide limits எப்போதும் பொருந்தும், workspace limits அவற்றின் கூட்டுத்தொகையை விட அதிகமாக இருந்தாலும் இது பொருந்தும். ஒரு workspace-ல் நீங்கள் limit-ஐ override செய்யவில்லை என்றால், அது organization-லிருந்து பெறப்படும் (inherited), அது unlimited ஆக இருக்காது.

Start, Build, Scale மற்றும் Custom எனப் பெயரிடப்பட்ட tiers, உங்கள் usage history மற்றும் account standing அடிப்படையில் தானாகவே நிர்ணயிக்கப்படும் எண்களைத் தீர்மானிக்கின்றன. புதிய organizations-களுக்குத் தரப்பட்ட standard limits-ஐ விடக் குறைந்த அளவில் தொடக்கம் இருக்கலாம், எனவே அட்டவணையில் உள்ளதை விடவே முதல் 429 error விரைவாக வரலாம். Usage திடீரென அதிகரித்தால் acceleration limits தூண்டப்படும். நீங்கள் உங்கள் tier-க்குள் இருந்தாலும் இவை 429 error-ஐத் தரும், எனவே traffic-ஐப் படிப்படியாக அதிகரிக்கவும். வெளியிடப்பட்ட ஒவ்வொரு எண்ணும் ஒரு ceiling ஆகும்: documented limits என்பது அனுமதிக்கப்பட்ட அதிகபட்ச usage மட்டுமே, அவை உத்தரவாதம் அளிக்கப்பட்ட குறைந்தபட்ச அளவுகள் (guaranteed minimums) அல்ல. அதிக limit கோர, Claude Console-ல் உள்ள Limits பக்கத்தில் உள்ள "Request rate limit increase" control-ஐப் பயன்படுத்தவும்.

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-ஐ மீண்டும் முயற்சிக்க (retry) காத்திருக்க வேண்டிய வினாடிகளின் எண்ணிக்கை ஆகும். முன்னதாகவே retry செய்தால் அது தோல்வியடையும்.
• 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-இன் மதிப்புகளைக் காட்டுகிறது.

Reset headers என்பவை RFC 3339 timestamps ஆகும். Remaining token headers அருகிலுள்ள ஆயிரம் (thousand) மதிப்பிற்குத் தள்ளுபடி செய்யப்படுகின்றன (rounded), எனவே அவற்றை ஒரு 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-இலும் req_018EeWyXxfu5pfWkrYcMdjWG போன்ற ஒரு தனித்துவமான request-id header இருக்கும். இது error bodies-இல் request_id ஆகவும், Python மற்றும் TypeScript SDK responses-களில் _request_id ஆகவும் தோன்றும். நீங்கள் support-ஐத் தொடர்பு கொள்ளும்போது இதை மேற்கோள் காட்டவும் (quote).

நீங்கள் ஒரு backoff loop-ஐ எழுதுவதற்கு முன், உங்களுக்கு அது உண்மையில் தேவையா என்பதைச் சரிபார்க்கவும். அதிகாரப்பூர்வ SDK-கள் connection errors, rate limits மற்றும் 5xx server errors போன்ற தற்காலிகத் தோல்விகளை (transient failures) exponential backoff முறையில் தானாகவே retry செய்யும். இயல்பாக (default) இது இரண்டு முறை நடக்கும், மேலும் 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 தற்காலிகமாக overloaded ஆக உள்ளது என்பதைக் குறிக்கிறது. அனைத்து பயனர்களிடமிருந்தும் அதிக traffic வரும்போது இது நிகழலாம். உங்கள் key அல்லது உங்கள் code-ஆல் இது ஏற்படவில்லை. SDK-கள் 5xx responses-களுக்கு ஏற்கனவே பயன்படுத்தும் exponential backoff முறையைப் பயன்படுத்தி மீண்டும் முயற்சிக்கவும். பிரச்சனை நீடித்தால் status.claude.com தளத்தைச் சரிபார்க்கவும். 500 api_error என்பது ஒரு internal error; இதையும் அதே முறையில் மீண்டும் முயற்சிக்கலாம். இவை இரண்டும் rate limit கிடையாது.

ஒரு அட்டவணையைப் பார்ப்பதற்குப் பதிலாக உங்கள் சொந்த வரம்புகளைப் படிக்கவும்

ஒரு subscription-இல், /usage என்பது மிக முக்கியமான screen ஆகும். இது உங்கள் plan usage bars மற்றும் பயன்பாட்டிற்கான காரணிகளின் விவரங்களைக் காட்டுகிறது. மேலும், d அல்லது w மூலம் கடந்த 24 மணிநேரம் மற்றும் கடந்த 7 நாட்களுக்கு இடையில் மாற்றிக்கொள்ளலாம். இதில் இரண்டு முக்கியக் குறிப்புகள் உள்ளன. Session block ஆனது API token usage-ஐக் காட்டுகிறது; இது API பயனர்களுக்காக மட்டுமே உருவாக்கப்பட்டது, எனவே 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 ஆனது, உங்கள் தற்போதைய ITPM limit-க்கு எதிராக நிமிடத்திற்கு ஒரு மணிநேரத்தின் அதிகபட்ச uncached input tokens எண்ணிக்கையைத் தீர்மானிக்கிறது. அதன் பக்கத்தில் உங்கள் cache rate காட்டப்படும், இதன் மூலம் production சூழலில் limit-ஐ எட்டுவதற்கு முன்பே நீங்கள் அதைக் கண்காணிக்க முடியும்.

உங்கள் 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-ஐப் பயன்படுத்தவும்.

less முறையைப் பயன்படுத்துவதன் மூலம் வரம்புகளைக் குறைத்தல்

இரண்டு அமைப்புகளும் அடிப்படையாக ஒரே விஷயத்தையே அளவிடுகின்றன, எனவே இந்த முறைகள் இரண்டிற்கும் பொருந்தும்.

• ஒவ்வொரு turn-க்கும் குறைவான tokens செலவிடுங்கள். தொடர்ச்சியான செயல்பாடுகள் cache-ஐத் தக்கவைக்க உதவும், மேலும் தொடர்பற்ற பணிகளுக்கு இடையே /clear செய்வது கூடுதல் செலவை ஏற்படுத்தாது. Claude Code token usage குறித்த விரிவான தகவல்கள் இந்த முறைகளை விளக்குகின்றன.
• முயற்சிகளை (effort) குறைக்கவும். இதன் நிலைகள் low, medium, high, xhigh மற்றும் max ஆகும். /effort menu-வில் ultracode என்ற விருப்பமும் உள்ளது, இது செலவைக் குறைப்பதற்குப் பதிலாக அதிகரிக்கும். ஒரு சாதாரண rename பணிக்காகத் தேவையற்ற deep reasoning முறையைப் பயன்படுத்துவது பயனற்றது.
• 429 error வந்தவுடன் concurrency-ஐக் குறைக்கவும். CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY அளவைக் குறைக்கவும் மற்றும் ஒரே நேரத்தில் பல parallel subagents-களைப் பயன்படுத்துவதைத் தவிர்க்கவும். /status முறையையும் பயன்படுத்தவும்: ஒரு stray ANTHROPIC_API_KEY உங்கள் subscription-க்குப் பதிலாக low-tier key வழியாக கோரிக்கைகளை அனுப்பும்.
• non-interactive பணிகளை Message Batches API-க்கு மாற்றவும். இது பெரிய அளவிலான தரவுகளை asynchronous முறையில் கையாள்கிறது. இதில் input மற்றும் output tokens-களுக்கு 50% தள்ளுபடி உண்டு. இது தனக்கெனத் தனி rate limits-களைக் கொண்டிருப்பதால், இரவு நேர வேலைகள் (nightly jobs) உங்கள் session-உடன் மோதாது.

ஒரு மனிதரால் அல்லாமல், ஒரு program மூலம் இயக்கப்படும் 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

ஏன் model-ஐ மாற்றுவது எனது Claude usage limit-ஐ சரிசெய்யவில்லை?

ஏனென்றால் session மற்றும் weekly limits அனைத்து models-களுக்கும் பொதுவானவை. இந்த allotment plan-ஐச் சார்ந்தது, ஒரு குறிப்பிட்ட model-ஐச் சார்ந்தது அல்ல. எனவே /model என்பது எந்த model பதிலளிக்கும் என்பதை மட்டுமே மாற்றும், மீதமுள்ள allowance அளவை மாற்றாது. இதற்கு விதிவிலக்கு You've hit your Opus limit ஆகும், இது Opus requests-களுக்கு மட்டுமே பொருந்தும். அந்தச் சூழலில், model-ஐ மாற்றுவது முறையான தீர்வாகும்.

429 rate_limit_error என்பதன் பொருள் என்ன, நான் எவ்வளவு நேரம் காத்திருக்க வேண்டும்?

அந்த model class-க்கான rate limit-ஐ உங்கள் account எட்டியுள்ளது என்று அர்த்தம்: அதாவது per minute requests, per minute input tokens, அல்லது per minute output tokens. அந்த response-இல் காத்திருக்க வேண்டிய வினாடிகளைக் குறிக்கும் retry-after header இருக்கும், அதைவிட முன்னதாகச் செய்யும் retries தோல்வியடையும். அதிகாரப்பூர்வ SDK-கள் ஏற்கனவே rate limits மற்றும் 5xx errors-களுக்கு exponential backoff முறையைப் பயன்படுத்தி, அந்த header-ஐப் பின்பற்றி, இயல்பாகவே இரண்டு முறை retry செய்யும். உங்கள் tier limits-க்குள் இருக்கும்போதே 429 error வந்தால், அது திடீர் அதிகரிப்பினால் ஏற்படும் 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 பயனர்கள் ceiling-ஐத் தாண்டி usage வாங்க /usage-credits பயன்படுத்தலாம், அல்லது Team மற்றும் Enterprise பயனர்கள் admin-இடம் இதைக் கேட்கலாம்; இதற்கு /login மூலம் claude.ai login தேவை, API key authentication மூலம் இது சாத்தியமில்லை. இல்லையெனில், reset time வரை காத்திருக்கவும், அது Opus limit என்றால் model-ஐ மாற்றவும், அல்லது வேலையை ஒரு API key-க்கு மாற்றவும்; API key ஒரு குறிப்பிட்ட window-விற்குப் பதிலாக per minute அடிப்படையில் கணக்கிடும்.