Claude API-তে 429 এড়ান—token count আর cache-এর হিসাব আগে করুন
Claude API-তে অনুমানযোগ্য 429 কমাতে Messages request পাঠানোর আগে input token estimate করুন, তারপর সংশ্লিষ্ট model-এর RPM ও ITPM capacity না পাওয়া পর্যন্ত request queue-তে রাখুন। Claude-এর token-counting নির্দেশনা অনুযায়ী count endpoint একই ধরনের structured input নিয়ে message তৈরির আগেই input token-এর estimate দেয়; actual usage সামান্য আলাদা হতে পারে।
একটি combined token counter যথেষ্ট নয়: RPM, ITPM ও OTPM আলাদা limiter হিসেবে চালাতে হবে। Claude Platform-এর rate-limit নিয়মে এই তিন সীমার যেকোনোটি ছাড়ালে 429 ও সাধারণত retry-after পাওয়া যায়; তীব্র traffic বৃদ্ধিও acceleration limit ঘটাতে পারে। অধিকাংশ model-এ cache read ITPM-এ গণনা হয় না, তবে cache creation ও uncached input হয়—তাই আগের সফল cache hit যাচাই না করে estimated token বাদ দেওয়া নিরাপদ নয়।
Preflight count-কে admission check বানান
Messages payload তৈরির পর একই model, system prompt, client tools ও messages দিয়ে count endpoint ডাকুন। Python SDK-তে মূল pattern হতে পারে count = client.messages.count_tokens(**payload).input_tokens; এরপর limiter.acquire(model, requests=1, input_tokens=count) সফল হলেই client.messages.create(**payload) চালান। Count ও message creation-এর rate limit আলাদা হলেও production queue-তে উভয়ের ব্যর্থতা সামলানোর পথ রাখা দরকার।
TypeScript-এ সমতুল্য flow হলো const count = await client.messages.countTokens(payload), তারপর model-specific limiter-এ count.input_tokens reserve করে client.messages.create(payload) চালানো। একাধিক worker থাকলে process-local counter যথেষ্ট নয়: admission সিদ্ধান্তের জন্য shared atomic counter বা distributed token bucket ব্যবহার করুন, নইলে দুই worker একই অবশিষ্ট capacity ধরে request ছাড়তে পারে।
Preflight ফলকে চূড়ান্ত usage ধরে নেবেন না। Token counting caching logic প্রয়োগ করে না, আর model পরিবর্তন করলে নতুন model দিয়েই আবার count করা উচিত—বর্তমান documentation-এ নতুন tokenizer ব্যবহারের কারণে একই text-এর count modelভেদে বদলাতে পারে। Server-side web search, web fetch, code execution ও tool search, MCP connector এবং URL বা file source-সহ image/document count endpoint-এ প্রত্যাখ্যাত হতে পারে; সেসব ক্ষেত্রে Messages response-এর usage-ই actual হিসাবের ভিত্তি।
RPM, ITPM ও OTPM-এর জন্য পৃথক budget রাখুন
- RPM: প্রতিটি Messages call একটি request slot নেয়। ছোট prompt-সহ বহু automation job এই সীমায় আগে আটকে যেতে পারে।
- ITPM: uncached input এবং নতুন cache entry-তে লেখা token এই budget ব্যবহার করে। বড় stable context cache miss করলে চাপটি হঠাৎ বেড়ে যায়।
- OTPM: output তৈরি হওয়ার সঙ্গে বাস্তবে উৎপন্ন token গণনা হয়। কেবল max_tokens বড় রাখার কারণে পুরো মানটি OTPM থেকে আগাম কাটা হয় না।
Admission-এর সময় একটি request slot ও estimated input reserve করুন। OTPM-এর জন্য সাম্প্রতিক actual output-এর rolling হিসাব রাখুন; workload-এর পর্যবেক্ষিত উচ্চ percentile সাময়িক estimate হিসেবে ব্যবহার করা যায়, তবে এটি engineering policy—Claude API থেকে পাওয়া usage নয়। সফল response এলে reservation-কে actual usage দিয়ে reconcile করুন।
Limiter key-তে organization বা workspace, model pool এবং limiter type রাখুন। Documentation অনুযায়ী rate limit model বা model class অনুযায়ী পৃথক হতে পারে; তাই একটি model-এর queue পূর্ণ হলেই অন্যটির capacity খালি আছে ধরে routing বদলাবেন না। বিকল্প model বাছলে capability ও খরচের পাশাপাশি সেই model দিয়ে input আবার count করুন।
Cache read প্রমাণিত হলে তবেই ITPM কম ধরুন
Response usage-এ মোট input-এর হিসাব হলো cache_read_input_tokens + cache_creation_input_tokens + input_tokens। অধিকাংশ model-এর ITPM accounting-এ শেষের দুটি অংশ গণনা হয়, cache read হয় না; ব্যতিক্রমী model থাকতে পারে, তাই Console বা বর্তমান rate-limit configuration দেখে pool-এর নিয়ম স্থির করুন। Cache context window ছোট করে না—এটি পুনর্ব্যবহৃত prefix-এর rate-limit accounting, latency ও খরচে প্রভাব ফেলে।
অফিসিয়াল prompt-caching নির্দেশনা stable prefix-এর শেষে cache_control breakpoint বসাতে এবং usage-এর cache_creation_input_tokens ও cache_read_input_tokens দিয়ে ফল যাচাই করতে বলে। Prompt model-নির্দিষ্ট ন্যূনতম cacheable length-এর নিচে থাকলে caching নীরবে বাদ যেতে পারে; parallel request-এর জন্য প্রথম response শুরু হওয়ার আগে cache entry-ও পাওয়া যায় না।
তাই প্রথম request, মেয়াদোত্তীর্ণ entry, পরিবর্তিত prefix বা অজানা cache state-কে miss ধরে পুরো preflight count-এর ITPM capacity reserve করুন। আগের compatible request-এ cache_read_input_tokens > 0 দেখা গেলে এবং prefix, model ও cache lifetime অপরিবর্তিত থাকলেই প্রত্যাশিত cached অংশ বাদ দিয়ে admission estimate কমান। বড় conversation-এর পুরোনো অংশ বারবার বদলালে cache key বদলে যায়; তখন পুরোনো context ছোট করার কৌশল ও কাজে লাগতে পারে।
429-কে একই retry path-এ ফেলবেন না
- Response body থেকে কোন limiter অতিক্রম করেছে দেখুন এবং retry-after থাকলে তার আগে request পাঠাবেন না।
- Retry delay হিসেবে retry-after ও exponential backoff-এর calculated delay-এর বড়টি নিন; তারপর সীমিত random jitter যোগ করুন, যাতে সব worker একসঙ্গে পুনরায় request না পাঠায়।
- Delay শেষে সরাসরি API call না করে request-টি একই model-specific admission queue-তে ফেরত দিন। এতে retry-ও নতুন RPM ও ITPM capacity পেলে তবেই বের হবে।
- Retry-after অনুপস্থিত থাকলে error.details.error_code পরীক্ষা করুন। enforced_spend_limit_reached হলে সাধারণ backoff দিয়ে লাভ নেই; spend access ফেরার বা tier বদলানোর আগে request থামাতে হবে।
Acceleration limit-এর ক্ষেত্রে শুধু retry বাড়ালে নতুন burst তৈরি হতে পারে। Worker concurrency ধীরে বাড়ান, arrival spike queue-তে absorb করুন এবং drain rate স্থিতিশীল রাখুন। Rate-limit headers telemetry-তে রাখুন, কিন্তু input, cache ও output-এর actual reconciliation response usage থেকে করুন।
Production flow এক জায়গায়
- পূর্ণ payload বানিয়ে ব্যবহৃত model দিয়েই preflight token count নিন।
- Shared store-এ RPM ও estimated ITPM capacity atomically reserve করুন।
- আগের compatible cache read প্রমাণিত না হলে পুরো input-কে cache miss হিসেবে ধরুন।
- Request dispatch-এর পর usage থেকে cache read, cache creation, uncached input ও output সংরক্ষণ করে estimate reconcile করুন।
- 429 log-এ limiter, model, request ID, retry-after ও error code রাখুন; prompt-এর সংবেদনশীল content রাখবেন না।
- Retry-after-সচেতন jittered exponential backoff শেষে request-কে admission queue-তেই ফেরত দিন।
- Model pool ও concurrency আলাদা রাখুন এবং traffic ধাপে ধাপে বাড়ান।
এই flow-তে preflight count হলো estimate, response usage হলো actual ফল এবং cache hit হলো যাচাইযোগ্য state। তিনটিকে আলাদা রাখলে 429-এর কারণও আলাদা করা যায়—request rate, uncached input, output pressure, acceleration limit বা spend cap—এবং ভুল limiter-এ নির্বিচারে retry পাঠানোর ঝুঁকি কমে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।