Claude ব্যবহারের সীমা পেরোলে কী করবেন

Claude-এর ব্যবহারের সীমা কী?

Claude-এর ব্যবহারের সীমা দুটি পৃথক ব্যবস্থায় নির্ধারিত হয়। প্রথমে আপনাকে শনাক্ত করতে হবে কোন ব্যবস্থাটি আপনার অনুরোধ বন্ধ করেছে। Claude subscription (Pro, Max, Team বা Enterprise) model এবং Claude chat—উভয়ের মধ্যে ভাগ করা একটি rolling usage allowance দেয়। সীমা অতিক্রম করলে You've hit your session limit · resets 3:45pm-এর মতো একটি বার্তা দেখা যায়। Claude API অন্য বিষয় মাপে: প্রতি মিনিটে আপনি কত দ্রুত request এবং token পাঠাচ্ছেন। এই সীমা অতিক্রম করলে এটি rate_limit_error ধরনের HTTP 429 error এবং কত সেকেন্ড অপেক্ষা করতে হবে তা জানানো একটি retry-after header দেয়।

এই সমস্যাগুলোর সমাধান এক নয়। Subscription limit নির্ভর করে একটি নির্দিষ্ট window-এর মধ্যে আপনি কতটা ব্যবহার করেছেন তার ওপর। তাই reset হওয়া পর্যন্ত অপেক্ষা করতে হবে অথবা অতিরিক্ত usage কিনতে হবে। API rate limit নির্ভর করে এই মুহূর্তে আপনার request পাঠানোর গতির ওপর। গতি কমালে এটি কয়েক সেকেন্ডের মধ্যে সরে যায়।

Plan allowance এবং rate-limit tier-এর সংখ্যা প্রায়ই পরিবর্তিত হয়। তাই ভুল সংখ্যা দেওয়ার চেয়ে কোনো সংখ্যা না দেওয়াই ভালো। নিচের command-গুলো ব্যবহার করে নিজের limit দেখুন।

কোন সীমায় পৌঁছেছেন? সঠিক বার্তাটি পড়ুন

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 একই system-এর দীর্ঘতর window-এর limit।
• You've hit your Opus limit · resets 3:45pm একটি subscription limit, যা শুধু Opus request-এর ক্ষেত্রে প্রযোজ্য। 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-এ আপনি পৌঁছে গেছেন। কোনটি প্রযোজ্য, তা নির্ভর করে client কীভাবে authenticate করে তার ওপর। কারণ Bedrock বা Vertex client-এর usage Anthropic organization-এর পরিবর্তে আপনার cloud project-এর quota থেকে গণনা করা হয়।
• API Error: Server is temporarily limiting requests (not your usage limit) একটি স্বল্পস্থায়ী throttle, যা আপনার plan quota-এর সঙ্গে সম্পর্কিত নয়। Claude Code এই line দেখানোর আগে backoff ব্যবহার করে স্বয়ংক্রিয়ভাবে retry করে।

সাবস্ক্রিপশন সীমা: session, weekly এবং Opus window

একটি subscription plan-এ rolling usage allowance থাকে। এই allowance শেষ হয়ে গেলে, message-এ দেখানো reset time পর্যন্ত Claude Code আর কোনো request গ্রহণ করে না। এই allowance-এর 2টি বৈশিষ্ট্য থেকেই বেশিরভাগ বিভ্রান্তি তৈরি হয়।

• এটি Claude chat-এর সঙ্গে shared। claude.ai-তে আপনার কাজ terminal-এর কাজের মতো একই allowance থেকে usage কমায়। তাই chat-এ বিকেলজুড়ে বেশি কাজ করলে coding-এর জন্য সন্ধ্যায় কম allowance থাকে। আপনি ওই account দিয়ে যেসব surface-এ sign in করেন, সবগুলো একই pool থেকে allowance ব্যবহার করে। তাই Linux-এ beta desktop app এবং Claude Code CLI মিলে একটি allowance ব্যবহার করে, প্রতিটির জন্য আলাদা allowance নয়।
• এটি বিভিন্ন model-এর মধ্যেও shared। Session এবং weekly limit-এর জন্য model-ভিত্তিক আলাদা budget নেই। শুধু Opus limit-এর ক্ষেত্রে ব্যতিক্রম প্রযোজ্য।

Claude for Teams এবং Enterprise-এ documentation অনুযায়ী, প্রতি seat-এর জন্য একটি allowance থাকে। এটি rolling five-hour window এবং weekly window অনুযায়ী reset হয়। Claude chat এবং Cowork-এর সঙ্গে এটি shared থাকে। Seat tier (Standard বা Premium) অনুযায়ী allowance-এর পরিমাণ নির্ধারিত হয়। Pro এবং Max-এ message-এ দেখানো reset time এবং আপনার নিজস্ব /usage bar-ই নির্ভরযোগ্য তথ্য। কোনো blog post থেকে কপি করা সংখ্যা নির্ভরযোগ্য নয়। আপনি যদি এখনও tier বেছে নিচ্ছেন, আপনার কোন Claude plan প্রয়োজন প্রতিটি plan কী কী সুবিধা নিয়ন্ত্রণ করে তা তুলনা করে।

/model ব্যবহার করে model বদলালে access কেন ফিরে আসে না

এটি সবচেয়ে সাধারণ ভুল পদক্ষেপ। Documentation-এ বিষয়টি স্পষ্টভাবে বলা আছে: session limit এবং weekly limit সব model-এর মধ্যে shared থাকে। তাই model বদলালে access ফিরে আসে না। আপনার session window-এর allowance শেষ হয়ে যাওয়ার পরে ছোট model নির্বাচন করলে শুধু কোন model উত্তর দেবে তা বদলায়। অবশিষ্ট allowance-এর পরিমাণ বদলায় না। কারণ allowance কখনো model-ভিত্তিক ছিল না। তাই switch করার পর release করার মতো কিছু থাকে না।

ব্যতিক্রম হলো Opus limit। এটি সত্যিই model-specific ceiling। Message-এ You've hit your Opus limit দেখা গেলে /model হলো সঠিক সমাধান। অন্য model-এ switch করে কাজ চালিয়ে যান, কারণ শুধু Opus request-গুলো blocked হয়েছে।

Limit-কে bug হিসেবে বিবেচনা করা দ্বিতীয় ভুল পদক্ষেপ। Reinstall বা re-authenticate করলেও কিছু পরিবর্তন হয় না। Window reset হলে অথবা usage credit কিনলে allowance ফিরে আসে।

সাবস্ক্রিপশন সীমায় পৌঁছালে যা করবেন

1. Reset হওয়ার সময় দেখুন। Session window স্বল্প সময়ের। Weekly window ডেস্কে বসে অপেক্ষা করে শেষ করার মতো নয়।
2. এটি Opus limit হলে /model চালিয়ে অন্য model বেছে নিন।
3. আপনার plan limit, bar এবং সেগুলো কখন reset হবে তা দেখতে /usage চালান। একই screen-এর alias হলো /cost।
4. সীমা অতিক্রম করেও কাজ চালিয়ে যেতে /usage-credits চালান। Pro এবং Max-এ এটি আপনার billing settings খোলে। Team এবং Enterprise-এ এটি আপনার organization-এর usage settings খোলে। আপনার billing access না থাকলে এটি admins-এর কাছে request পাঠায়।
5. প্রতি সপ্তাহে একই সীমায় পৌঁছালে আপনার কাজের ধরন অনুযায়ী plan-এর size সঠিক নয়। প্রতিবার reset হওয়ার সময় না ভেবে একবারেই usage limit থেকে বের হওয়ার পথগুলো বিবেচনা করা ভালো।

/usage-credits ব্যবহারের জন্য /login-এর মাধ্যমে sign in করা claude.ai subscription প্রয়োজন। API key authentication-এর সঙ্গে এটি উপলভ্য নয়, কারণ API key-তে বাড়ানোর মতো কোনো plan allowance থাকে না।

Usage credits-এর একটি পার্শ্বপ্রতিক্রিয়া আগে জানা দরকার। Subscription ব্যবহারের সময় prompt cache এক ঘণ্টা সক্রিয় থাকে। Credits ব্যবহার শুরু করলে এটি পাঁচ মিনিটে নেমে আসে। ফলে আরও বেশি turn শুরুতে cache ছাড়া চলে, এবং একই কাজের জন্য Claude Code token usage বেড়ে যায়।

যে বার্তাগুলো usage limit-এর মতো দেখায়, কিন্তু আসলে তা নয়

Claude Code-এর চারটি error-কে usage limit হিসেবে জানানো হয়, কিন্তু কোনোটিই usage limit নয়।

• Context বা auto-compact warning usage limit নয়। কথোপকথন model-এর context window-এর সীমা পার হলে /context, Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.-এর মতো একটি line দেখায়। পুরোনো history সংক্ষেপ করে জায়গা খালি করা হয়, এবং আপনার 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 credit শেষ হয়ে গেছে। platform.claude.com/settings/billing-এ credit যোগ করুন। সেখানে 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 সেট করুন।

আরেকটি error API থেকে আসে। 413 request_too_large একটি একক request-এর size limit, rate limit নয়।

API rate limit: আসলে 429 কী গণনা করে

Messages API প্রতিটি model class-এর জন্য আলাদাভাবে 3টি বিষয় পরিমাপ করে।

• প্রতি মিনিটে request (RPM)
• প্রতি মিনিটে input token (ITPM)
• প্রতি মিনিটে output token (OTPM)

আপনার organization-এর একটি spend limit-ও থাকে। এটি আলাদা বিষয়: API ব্যবহারের জন্য মাসিক সর্বোচ্চ খরচ। আপনার tier-এর spend cap-এ পৌঁছে গেলে পরের মাস পর্যন্ত API ব্যবহার স্থগিত থাকে, যদি না আপনি উচ্চতর limit-এর অনুরোধ করেন। কোনো retry loop এটি সমাধান করতে পারে না।

4টি প্রক্রিয়া নির্ধারণ করে কখন 429 আসে।

• Limit প্রতি model class অনুযায়ী প্রযোজ্য। প্রতিটি model-এর জন্য এগুলো আলাদাভাবে প্রযোজ্য। তাই একই সময়ে প্রতিটি model-এর নিজস্ব limit পর্যন্ত ভিন্ন model ব্যবহার করা যায়। কিছু family একই bucket ভাগ করে: Opus rate limit হলো Claude Opus 4.8, Opus 4.7, Opus 4.6 এবং Opus 4.5-এর সম্মিলিত limit, আর Claude Sonnet 5-এর নিজস্ব limit আছে।
• Capacity ধারাবাহিকভাবে পুনরায় পূরণ হয়। API token bucket algorithm ব্যবহার করে। তাই নির্দিষ্ট কোনো সময়ে reset না হয়ে capacity ধারাবাহিকভাবে replenishing হয়। প্রতি মিনিটে 60টি request-এর limit বাস্তবে প্রতি সেকেন্ডে 1টি request হিসেবে প্রয়োগ হতে পারে। ফলে একসঙ্গে 60টি request পাঠালেও সেগুলো ব্যর্থ হতে পারে।
• বেশিরভাগ model-এ শুধু uncached input ITPM-এ গণনা হয়। input_tokens এবং cache_creation_input_tokens গণনা হয়। বেশিরভাগ Claude model-এ cache_read_input_tokens গণনা হয় না; Claude Haiku 3.5 হলো নথিভুক্ত ব্যতিক্রম। তাই caching rate limit-এর headroom বাড়ানোর পাশাপাশি খরচও কমায়। Output-এর ক্ষেত্রে উচ্চ max_tokens OTPM-এর বিপরীতে গণনা হয় না, কারণ OTPM-এ শুধু বাস্তবে তৈরি হওয়া token গণনা করা হয়।
• Limit organization স্তরে নির্ধারিত থাকে। কোনো workspace-কে কম limit দেওয়া যেতে পারে। Workspace-এর limit যোগ করে বেশি হলেও organization-wide limit সবসময় প্রযোজ্য। কোনো workspace-এ আপনি limit override না করলে সেটি organization থেকে inherited হয়; unlimited থাকে না।

Start, Build, Scale এবং Custom নামে tier-গুলো প্রকৃত সংখ্যাগুলো নির্ধারণ করে। আপনার usage history এবং account standing-এর ভিত্তিতে এগুলো স্বয়ংক্রিয়ভাবে নির্ধারিত হয়। নতুন organization standard published limit-এর চেয়ে কম limit দিয়ে শুরু করতে পারে। তাই কোনো table-এর পূর্বাভাসের চেয়েও আগে প্রথম 429 আসতে পারে। Usage হঠাৎ বেড়ে গেলে acceleration limit সক্রিয় হয়। আপনি নিজের tier-এর সীমার মধ্যেই থাকলেও এটি 429 ফেরত দিতে পারে। তাই traffic ধীরে ধীরে বাড়ান। প্রতিটি published figure হলো সর্বোচ্চ সীমা। Documented limit হলো অনুমোদিত ব্যবহারের maximum, guaranteed minimum নয়। উচ্চতর limit চাইতে Claude Console-এর Limits page-এ থাকা "Request rate limit increase" control ব্যবহার করুন।

429-এর প্রতিক্রিয়া পড়া: retry-after, header এবং SDK retry

প্রতিটি API error একই envelope ফেরত দেয়: একটি nested error object, যাতে type ও message থাকে, এবং একটি top-level request_id।

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

বাকি তথ্য header-গুলোতে থাকে।

• retry-after হলো request পুনরায় চেষ্টা করার আগে অপেক্ষার সময়, সেকেন্ডে। এর আগে 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 suffix থাকে।
• anthropic-ratelimit-tokens-* বর্তমানে কার্যকর সবচেয়ে কঠোর limit-এর মান দেখায়।

Reset header-গুলো RFC 3339 timestamp। Remaining token header-গুলোর মান নিকটতম হাজারে round করা থাকে। তাই এগুলোকে আনুমানিক সূচক হিসেবে পড়ুন। Fast mode-এর নিজস্ব pool এবং নিজস্ব anthropic-fast-* header রয়েছে। যেকোনো সফল call থেকে সবগুলো header পড়ুন:

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 body-তে এটি request_id হিসেবে এবং Python ও TypeScript SDK response-এ _request_id হিসেবে দেখা যায়। Support-এর সঙ্গে যোগাযোগ করার সময় এটি উল্লেখ করুন।

Backoff loop লেখার আগে দেখুন, আদৌ সেটি প্রয়োজন কি না। Official SDK-গুলো connection error, rate limit এবং 5xx server error-সহ transient failure স্বয়ংক্রিয়ভাবে retry করে। এগুলো exponential backoff ব্যবহার করে এবং default হিসেবে দুইবার retry করে। retry-after header থাকলে SDK তা অনুসরণ করে। প্রতিটি 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 status code বোঝায় যে আপনি খুব দ্রুত অনুরোধ পাঠিয়েছেন। 529 overloaded_error status code বোঝায় যে API সাময়িকভাবে অতিরিক্ত লোডে রয়েছে। সব ব্যবহারকারীর মিলিত network traffic বেড়ে গেলে এটি ঘটতে পারে। এর জন্য আপনার key বা code দায়ী নয়। Exponential backoff ব্যবহার করে আবার চেষ্টা করুন। 5xx response-এর ক্ষেত্রে SDK-গুলো ইতিমধ্যে এটি করে। সমস্যা না কাটলে status.claude.com দেখুন। 500 api_error একটি internal error। একইভাবে আবার চেষ্টা করুন। কোনোটিই rate limit নয়।

টেবিলের বদলে নিজের সীমা দেখুন

Subscription-এ /usage হলো গুরুত্বপূর্ণ screen। এখানে আপনার plan-এর usage bar এবং কোন কাজে কতটা usage হয়েছে তার breakdown দেখা যায়। d বা w ব্যবহার করে শেষ 24 ঘণ্টা এবং শেষ 7 দিনের মধ্যে পরিবর্তন করা যায়।

দুটি বিষয় মনে রাখুন। Session block-এ API token usage দেখানো হয় এবং এটি API user-দের জন্য তৈরি। তাই subscriber-রা সেখানে দেখানো dollar figure উপেক্ষা করতে পারেন। এই সংখ্যাগুলো ওই machine-এর local session history থেকে নেওয়া হয়। তাই অন্য device বা claude.ai থেকে হওয়া usage এখানে দেখা যায় না।

API-এর ক্ষেত্রে Claude Console-এর Usage page-এ "Rate Limit - Input Tokens" এবং "Rate Limit - Output Tokens" নামে দুটি chart থাকে। Input chart-এ প্রতি মিনিটে uncached input token-এর hourly maximum এবং আপনার বর্তমান ITPM limit তুলনা করে দেখানো হয়। পাশে cache rate-ও থাকে। এতে production-এ limit-এ পৌঁছানোর আগেই আপনি তা monitor করতে পারেন।

Programmatically configured limit দেখতে:

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-এ কম token খরচ করুন। একটানা কাজ করলে cache উষ্ণ থাকে, আর সম্পর্কহীন কাজের মধ্যে /clear করতে কোনো খরচ হয় না। Claude Code-এর token ব্যবহার এই নিয়ন্ত্রণগুলোর বিস্তারিত ব্যাখ্যা দেয়।
• effort কমান। স্তরগুলো হলো low, medium, high, xhigh এবং max। /effort menu-তে ultracode-ও আছে, যা খরচ কমানোর পরিবর্তে বাড়ায়। যান্ত্রিক rename-এর জন্য গভীর reasoning ব্যবহার করে কোনো লাভ নেই।
• 429 পাওয়ার পরে concurrency কমান। CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY কমান এবং অনেক parallel subagent এড়িয়ে চলুন। /status-ও চালান: একটি অবশিষ্ট ANTHROPIC_API_KEY request-গুলোকে আপনার subscription-এর পরিবর্তে low-tier key-এর মাধ্যমে পাঠাতে পারে।
• non-interactive কাজ Message Batches API-তে সরান। এটি নিজস্ব rate limit-এর অধীনে বড় পরিমাণের কাজ asynchronousভাবে চালায় এবং input ও output token-এ 50% discount দেয়। ফলে nightly job আপনার session-এর সঙ্গে প্রতিযোগিতা করা বন্ধ করে।

যে কাজে context-এর মধ্যে বিপুল পরিমাণ data ঢোকে, সেখানে এই সমস্যাটি সবচেয়ে বেশি অনুভূত হয়। আপনি যদি live market data ব্যবহার করে stock ও option বিশ্লেষণ করেন, প্রতিটি প্রশ্নের জন্য প্রয়োজনীয় সীমিত অংশ নেওয়ার খরচ সম্পূর্ণ quote ও chain-এর table paste করার তুলনায় অনেক কম। কোনো ব্যক্তির পরিবর্তে program-চালিত bursty কাজ শুরু থেকেই API key-তে রাখা উচিত। সেখানে স্থানান্তর করলে metering-এর পাশাপাশি অর্থপ্রদানের পদ্ধতিও বদলে যায়, কারণ Claude API-তে free tier নেই; signup-এর সময় দেওয়া সামান্য credit-টুকু এর ব্যতিক্রম। VPS-এ আপনার প্রথম Claude API app-এ key পরিচালনা ও retry-এর পদ্ধতি ব্যাখ্যা করা হয়েছে। দীর্ঘ agent run-এর সময় connection বিচ্ছিন্ন হলেও tmux-এর ভেতরে VPS-এ Claude Code চালু রাখলে কাজ চলতে থাকে।

FAQ

মডেল পরিবর্তন করলে Claude-এর usage limit কেন ঠিক হয় না?

কারণ সব মডেলের জন্য session limit এবং weekly limit একইভাবে ভাগ করা হয়। allowance কোনো নির্দিষ্ট মডেলের নয়, plan-এর অন্তর্ভুক্ত। তাই /model কোন মডেল উত্তর দেবে তা পরিবর্তন করে, কিন্তু অবশিষ্ট allowance-এর পরিমাণ পরিবর্তন করে না। একমাত্র ব্যতিক্রম হলো You've hit your Opus limit, যা শুধু Opus request-এর ক্ষেত্রে প্রযোজ্য। সেই ক্ষেত্রে মডেল পরিবর্তন করাই নথিভুক্ত সমাধান।

429 rate_limit_error-এর অর্থ কী, এবং কতক্ষণ অপেক্ষা করা উচিত?

এর অর্থ হলো আপনার account ওই model class-এর rate limit-এ পৌঁছেছে: প্রতি মিনিটে request, প্রতি মিনিটে input token, অথবা প্রতি মিনিটে output token-এর সীমা। Response-এ retry-after header থাকে, যেখানে কত সেকেন্ড অপেক্ষা করতে হবে তা দেওয়া থাকে; এর আগে retry করলে তা ব্যর্থ হবে। Official SDK-গুলো rate limit এবং 5xx error-এর জন্য exponential backoff ব্যবহার করে স্বয়ংক্রিয়ভাবে retry করে। Default হিসেবে তারা 2 বার retry করে এবং ওই header-এর নির্দেশনা মেনে চলে। আপনি tier-এর নির্ধারিত সীমার মধ্যেই থাকা অবস্থায় 429 পেলে, সেটি হঠাৎ request বৃদ্ধির কারণে acceleration limit কার্যকর হওয়ার ইঙ্গিত।

Claude-এর usage limit এবং কখন reset হবে তা কীভাবে দেখব?

Claude Code-এ আপনার plan bar, reset time এবং usage breakdown দেখতে /usage চালান। /cost একটি alias। d অথবা w ব্যবহার করে শেষ 24 ঘণ্টা এবং শেষ 7 দিনের মধ্যে পরিবর্তন করুন। এই পরিসংখ্যান local session history থেকে নেওয়া হয়। তাই এতে অন্য device এবং claude.ai থেকে হওয়া usage অন্তর্ভুক্ত থাকে না। API-এর ক্ষেত্রে Console আপনার rate limit-এর chart দেখায়। Admin API key ব্যবহার করে GET /v1/organizations/rate_limits চালালে configured limit ফেরত পাওয়া যায়।

Claude plan limit-এ পৌঁছানোর পরও কি কাজ চালিয়ে যেতে পারি?

কখনও কখনও পারেন। Pro এবং Max-এ ceiling অতিক্রম করে usage কেনার জন্য /usage-credits চালান। Team এবং Enterprise-এ admin-এর কাছে usage অনুমোদনের অনুরোধ করতেও এটি ব্যবহার করা যায়। এর জন্য /login-এর মাধ্যমে claude.ai login প্রয়োজন। API key authentication ব্যবহার করলে এটি উপলভ্য নয়। অন্যথায় reset time পর্যন্ত অপেক্ষা করুন। সীমাটি Opus-এর হলে model পরিবর্তন করুন। অথবা কাজটি API key-এ স্থানান্তর করুন, যেখানে usage প্রতি window-এর বদলে প্রতি মিনিটে মাপা হয়।