Claude Code साप्ताहिक उपयोग सीमा

• Anthropic की Claude Code सेवा के लिए साप्ताहिक उपयोग सीमा लागू की गई है
• यह मुफ्त और पेड, दोनों तरह के यूज़र्स पर लागू होती है
• यूज़र्स को एक हफ्ते के दौरान अधिकतम query count या प्रोसेस किए गए token की मात्रा की सीमा का पालन करना होगा
• यह सीमा सेवा के दुरुपयोग को रोकने और system resources की स्थिरता सुनिश्चित करने के उद्देश्य से लाई गई है
• डेवलपर्स और startups को API उपयोग करते समय resource management पर अतिरिक्त ध्यान देने की आवश्यकता होगी

---

Claude Code साप्ताहिक उपयोग सीमा लागू होने का सार

Anthropic द्वारा प्रदान की जाने वाली Claude Code सेवा पर नई साप्ताहिक उपयोग सीमा नीति लागू की गई है

• सभी यूज़र्स (मुफ्त और पेड) के लिए एक निश्चित मात्रा में queries या token उपयोग सीमा तय की गई है
• यह सीमा सेवा के दुरुपयोग को रोकने, निष्पक्ष सेवा उपलब्ध कराने, और infrastructure resources की स्थिरता सुनिश्चित करने के लिए लागू की गई है
• हर हफ्ते सीमा रीसेट होगी, और सीमा पार होने पर उस सप्ताह अतिरिक्त उपयोग संभव नहीं होगा

डेवलपर्स और startups पर मुख्य प्रभाव

• प्रोडक्ट डेवलपमेंट में Claude Code का उपयोग करते समय usage planning की आवश्यकता बढ़ेगी
• API integration सेवाओं में automated management या limit exceed alert logic लागू करने की ज़रूरत पैदा होगी
• बड़े पैमाने पर code generation, analysis, और repeated calls करने की स्थिति में resource utilization optimization का महत्व बढ़ेगा

निष्कर्ष

• Claude Code की साप्ताहिक उपयोग सीमा नीति का उद्देश्य sustainability और सेवा गुणवत्ता में सुधार है
• startups और IT professionals को मौजूदा system integration और service design करते समय साप्ताहिक सीमा की जांच तथा उपयोग योजना बनानी होगी

[GN⁺]

Hacker News राय

• शायद मैं साप्ताहिक limit तक नहीं पहुँचूँगा, लेकिन यह असहज करता है कि limit 36 घंटे जैसी विंडो में नहीं बल्कि साप्ताहिक आधार पर है
  अगर limit hit हो गई, तो उस पूरे हफ्ते इस्तेमाल नहीं कर पाऊँगा
  जिस टूल की आदत पड़ गई हो, उसे इतने लंबे समय तक न इस्तेमाल कर पाना असुविधाजनक है
  कोई कह सकता है कि मैं Claude पर बहुत निर्भर हूँ, लेकिन ripgrep जैसे दूसरे टूल्स के साथ भी यही बात है
  कुछ दिन न इस्तेमाल करना ठीक है, लेकिन एक हफ्ता बहुत लंबा है
  और यह भी ध्यान खींचता है कि उन्होंने कहा केवल “5% से कम users” प्रभावित होंगे
  आम तौर पर ऐसी घोषणाएँ कहती हैं कि 1% से कम लोग प्रभावित होंगे, लेकिन Anthropic कह रहा है कि 20 में 1 व्यक्ति limit पार करेगा

  • ChatGPT Plus प्लान में o3 की 100 बार/हफ्ता limit बिल्कुल ऐसा ही महसूस होती है
    यह भी पता नहीं चलता कि कितना इस्तेमाल कर लिया, और क्योंकि यह एक महत्वपूर्ण resource है, स्वाभाविक रूप से उसे बचाकर इस्तेमाल करने लगते हैं
    आखिरकार प्लान का ठीक से उपयोग नहीं कर पाते और o4-mini जैसे मॉडल पर चले जाते हैं
    बेहतर होता कि daily limit होती
    लेकिन शायद weekly limit का इरादा ही यह है कि लोग limit तक न पहुँचें और बचाकर इस्तेमाल करें

  • यह दुखद है कि developers अब exclusive online services पर निर्भर होते जा रहे हैं
    पहले हर काम FOSS tools से किया जा सकता था, और किसी खास कंपनी या service को monthly subscription देकर बँधना नहीं पड़ता था
    अब कुछ लोग Monsanto के किसानों की तरह हो गए हैं, जो हर महीने पैसे देकर टूल इस्तेमाल करते हैं और उसके बिना काम करना भूलते जा रहे हैं

  • मैं sonnet के साथ Pro limit तक अक्सर दिन में 3 बार पहुँच जाता हूँ
    Claude code और claude को साथ में चलाऊँ तो 30 मिनट में ही खत्म हो जाता है
    मैं 24/7 multi-agent या कई windows भी नहीं चलाता, फिर भी ऐसा होता है
    मुझे नहीं लगता कि मैं top 5% user हूँ, लेकिन बुधवार तक limit खत्म हो जाना अब चौंकाने वाला नहीं है
    अब जाकर Claude chat को ज़्यादा इस्तेमाल करने की सोच रहा था, लेकिन अगर कई दिनों तक भरोसे से इस्तेमाल ही न कर सकूँ तो उसका मतलब नहीं

  • Anthropic कह रहा है कि 20 में 1 व्यक्ति limit तक पहुँचेगा, लेकिन ऐसा नहीं लगता कि account sharing या 24/7 automation users इतने ज़्यादा होंगे

  • अगर limit लग भी जाए तो पूरे हफ्ते के लिए बंद नहीं होगा, बस उस हफ्ते का बाकी समय इस्तेमाल नहीं कर पाओगे
    उन्होंने खुद भी कहा कि शायद तुम बहुत कम ही इस तक पहुँचोगे, इसलिए अगर पहुँचो भी तो संभव है कि हफ्ते के आखिरी 36 घंटों में हो
    API के लिए पैसे देकर इस्तेमाल करने का रास्ता भी है

• लंबी अवधि में क्या होगा पता नहीं, लेकिन हर बार LLM इस्तेमाल करते समय यह महसूस होना कि यह सीमित resource है, अच्छा नहीं लगता
  लोग unlimited plans के आदी हैं
  मौजूदा pricing model कुछ ज़बरदस्ती थोपे हुए जैसा लगता है, इसलिए असुविधाजनक है

  • unlimited हर उस service के लिए ठीक है जो “इतनी सस्ती हो कि मापना भी न पड़े”
    internet, text messaging वगैरह में direct cost बहुत कम होती है, इसलिए ऐसा चल सकता है
    लेकिन LLM में अभी भी हर run पर काफी direct cost लगती है

  • मैं इस संरचना से सहमत नहीं हूँ कि पूरे महीने usage steady रहने की उम्मीद की जाए
    मैं अक्सर पूरे महीने इस्तेमाल नहीं करता, लेकिन कुछ दिनों में 11-11 घंटे लगातार इस्तेमाल करता हूँ, और तब ज़्यादातर limit से टकरा सकता हूँ
    इसीलिए API सीधे इस्तेमाल करना बेहतर लगता है, क्योंकि वहाँ limit मेरे wallet की गहराई के हिसाब से तय होती है
    OpenRouter जैसी चीज़ इस्तेमाल करो तो subscription model की सीमाएँ भी टाली जा सकती हैं
    आजकल Gemini 2.5 Pro, code work के लिए Claude से ज़्यादा बेहतर फिट बैठता है
    इसके अलावा और कौन-से cost-competitive options हैं, यह जानने की उत्सुकता है
    https://docs.anthropic.com/en/api/rate-limits#rate-limits

  • मेरी राय में ऐसे tools में “$20/महीना”, “$200/महीना” जैसे plans देकर सीमित access देना और limit calculation को अस्पष्ट बनाना ही खत्म कर देना चाहिए
    इन्हें पूरी तरह usage-based होना चाहिए, तभी यह सच में user-friendly होगा
    trial के लिए शुरुआती 20 uses free जैसी free tier दे सकते हैं, या usage के हिसाब से step pricing रख सकते हैं, और extreme users से actual cost के अनुरूप charge लेना चाहिए
    इससे low-usage users सस्ते में इस्तेमाल कर पाएँगे, और market share भी मिल सकता है
    अगर OpenRouter से बेहतर price मिले, तो लोग third-party tools की जगह इसी ecosystem में बने रहेंगे
    अगर tool सच में अच्छा है, तो usage-based होने पर भी users टिके रहेंगे
    समस्या यह है कि providers market share के लिए users को subsidize भी करना चाहते हैं, और abuse या extreme usage को रोकना भी चाहते हैं
    100% समाधान पूरी तरह usage-based, बिना entry fee वाली संरचना है
    लेकिन ऐसा होने पर जो लोग सिर्फ subscription लेकर कम इस्तेमाल करते हैं, वे नुकसान में दिखेंगे, इसलिए sales team शायद इसका विरोध करेगी
    और इससे लोगों के लिए इधर-उधर price compare करके move करना भी आसान हो जाएगा, यानी एक-दो महीने तक बँधे रहने वाली भावना भी खत्म हो जाएगी

  • लंबी अवधि में local LLM, 2025 के सबसे अच्छे cloud LLM से भी बेहतर हो जाएगा, और रोज़मर्रा के 99% काम unlimited तरीके से हो पाएँगे
    सिर्फ सच में complex problems के लिए cloud से जुड़ना पड़ेगा
    LLM efficiency बेहतर होगी, और GPU, memory, storage की लागत भी लगातार घटेगी और accessibility बढ़ेगी
    अभी बस transition period है, इसलिए थोड़ा असुविधाजनक दिख रहा है

  • resource सीमित हो तो भी ठीक है, अगर मुझे यह तो पता हो कि मैंने कितना इस्तेमाल किया है
    progress दिखाई न देना ही असुविधाजनक है

• Max 5x और Max 20x के फर्क को लेकर उलझन है
  मेरे email में लिखा है कि “ज़्यादातर Max 20x users, Sonnet 4 को हफ्ते में 240~480 घंटे और Opus 4 को 24~40 घंटे इस्तेमाल कर सकते हैं”
  official announcement में लिखा है कि “ज़्यादातर Max 5x users, Sonnet 4 को हफ्ते में 140~280 घंटे और Opus 4 को 15~35 घंटे इस्तेमाल कर सकते हैं”
  बेहतर होता कि price के अनुपात में limit भी 2x से ज़्यादा होती, लेकिन Opus 4 में फर्क सिर्फ 5~9 घंटे का है
  कम से कम 2x तो होना चाहिए, जब कीमत भी दोगुनी है

  • अगर सच में ऐसा है, तो मैं तुरंत Max 20x से lower plan पर downgrade कर दूँगा
    ऑस्ट्रेलिया में मैं इसके लिए महीने के $350 दे रहा हूँ

  • मैं लगातार Opus limit से टकराता रहा, इसलिए 20x में upgrade किया, लेकिन अब दिख रहा है कि 20x और 5x में लगभग कोई फर्क ही नहीं है

  • इसलिए मैंने MAX इस्तेमाल करना बंद कर दिया और Pro पर downgrade करके o3 और दूसरे models को API से इस्तेमाल कर रहा हूँ
    शुरुआत में मुझे इतना ज़्यादा समय नहीं चाहिए होता, इसलिए project per लगभग $10 में o3, Gemini, Opus सब इस्तेमाल हो जाते हैं
    हर कुछ दिनों में नया model आ जाता है, इसलिए मैं सिर्फ एक provider में बँधना नहीं चाहता

  • वास्तव में usage दोगुनी नहीं होती, बस traffic spike के समय priority ज़्यादा मिलती है

  • अगर marketing materials सच से अलग हैं, तो अच्छा होगा कि कोई real data के साथ इसकी जाँच करे और class action lawsuit करे

• यह समझ आता है कि महीने के $200 भी पर्याप्त नहीं हैं
  तो फिर ऐसा plan होना चाहिए जिसमें limit की चिंता किए बिना इस्तेमाल किया जा सके
  “समय खत्म!” जैसा संदेश flow तोड़ देता है
  कम से कम credits model होता, तो पता रहता कितना खर्च हुआ और चाहें तो extra payment कर सकते
  “GPU ठंडा होने तक इंतज़ार” जैसी अवधारणा productivity में मदद नहीं करती
  अगर कई agents चलाओ, तो ‘35 घंटे’ बिल्कुल अपर्याप्त है
  अजीब यह भी है कि tool खुद ऐसे usage pattern को support करने के हिसाब से design किया गया है

  • अगर सबके लिए पर्याप्त और फिर भी profitable plan बनाया जाए, तो हो सकता है सभी users competitors की ओर निकल जाएँ
    users को tool पर निर्भर बना कर धीरे-धीरे price बढ़ाना शायद रणनीतिक रूप से बेहतर लग सकता है

  • “कई agents चलाना” मुझे नहीं लगता कि personal plan पर सामान्य use case है
    ऐसे मामलों में हमेशा API usage के लिए सीधे भुगतान करना पड़ता था
    fixed-price plan में यह allow करना service की उदारता थी, और शुरू से इसे “higher limits” कहा गया था, “unlimited” नहीं

  • API में limits कहीं ज़्यादा लचीली हैं, और व्यावहारिक रूप से लगभग कोई सीमा नहीं है
    Claude, Aws और gcp पर भी उपलब्ध है, इसलिए limits और credits भी अलग हैं और rates भी अलग-अलग हैं

  • policy को “अच्छे users” के हिसाब से optimize करना चाहिए, “बुरे users” के हिसाब से नहीं

  • बस API इस्तेमाल करो

• कुल मिलाकर देखें तो, जब कुछ users 24/7 कई agents चलाते हैं तब system को सुरक्षित रखकर
  ज़्यादा users को लगातार इस्तेमाल करने देने वाला यह एक सकारात्मक बदलाव लगता है
  लेकिन “कितना usage बचा है” यह न दिखना असुविधाजनक है
  चाहे प्रतिशत न भी बताएँ, कम से कम बीच-बीच में (जैसे आधा होने पर) alert मिल जाए तो planning आसान हो
  इसे न देने से यह एहसास होता है कि “शायद वे हमें इसे मापने ही नहीं देना चाहते”
  मुझे बहुत सटीक tracking नहीं चाहिए, बस मोटे तौर पर अपनी स्थिति जाननी है

• Anthropic Reddit account के अनुसार
  एक user ने $200 वाले plan पर कई दसियों हज़ार डॉलर के बराबर LLM इस्तेमाल किया
  कंपनी power users के लिए अलग solution बना रही है
  लेकिन नई limits का उद्देश्य अब ज़्यादा fair experience देना और account sharing तथा resale रोकना है
  इसी वजह से हम “अच्छी service” नहीं पा रहे हैं

  • जिस startup में मैं पहले था, वहाँ भी कभी unlimited option दिया गया था
    शुरुआत में लगा था कि कोई इतना ज़्यादा इस्तेमाल नहीं कर पाएगा, लेकिन असल में बहुत से users रचनात्मक तरीक़े से service limits को exploit करने लगे
    accounts 24/7 services से जुड़े रहते थे और request limit के 95% तक लगातार requests भेजते थे
    विभिन्न IPs का इस्तेमाल होता था, और patterns ऐसे थे जो इंसानों जैसे नहीं लगते थे
    शुरुआत में इसे outlier माना गया, लेकिन जब ऐसे accounts exponential rate से बढ़ने लगे
    तो असल में कई businesses कई accounts बनाकर load balancing कर रहे थे
    user-wise average profit/loss graphs देखने पर साफ था कि ऐसे accounts भारी नुकसान छोड़ते हुए resources को maximum तक खा रहे थे, और अंततः policy बदलनी पड़ी
    ऐसे “customers” खोते हैं, लेकिन ज़्यादातर सामान्य users पर कोई असर नहीं पड़ता
    बल्कि पूरी service अधिक सुचारु हो जाती है
    यह अनुभव हर high-usage startup को होता है

  • हो सकता है कंपनी वास्तव में service को घाटे में बेच रही हो

  • क्या मौजूदा limits से भी इस तरह के abuse को ID-स्तर पर रोका नहीं जा सकता? मुझे ठीक से समझ नहीं आता

  • कल किसी ने Twitter पर इस बारे में डींग मारी थी
    उसने कहा कि $200 account से $13,200 जितना usage किया, और 4~5 Opus-only agents को 24/7 recursive calls के साथ एक-दूसरे पर चलाया
    यह साफ़ तौर पर abuse है और इसे target किया जाना चाहिए
    लेकिन inference provider इसे ठीक-ठीक कैसे रोके, यह समझना आसान नहीं है
    Cursor में Anthropc/OpenAI की तुलना में और premium जुड़ने से स्थिति और कठिन हो गई है
    Anthropic भी लगभग उसी स्थिति में है, लेकिन यहाँ premium option नहीं है
    अगर $20 में महीने का actual cost सिर्फ $500 तक allow करो, तो वह भी आखिर 95% discount ही हुआ, और ऐसी संरचना टिक नहीं सकती
    ऐसे support से community में entitlement का माहौल और बढ़ जाता है
    जो चीज़ आदत बन गई हो, उसके छिनने जैसा लगता है, लेकिन cap/opex ही असहनीय हो तो R&D cost जोड़ने पर model को बनाए रखना भी मुश्किल हो जाता है
    इसलिए व्यावहारिक रूप से बस यही हो सकता है कि “price structure बदलते रहो और users अगली ज़्यादा उदार subsidy देने वाली कंपनी की तरफ़ चले जाएँ”
    बेहतर होता कि ऐसी policy को शुरू से trial कहा जाता, और कितना subsidy दिया जा रहा है यह transparently बताया जाता
    लोग model को आज़माते, कुछ रुकते भी, और कुछ churn होते तो भी शिकायत कम होती
    अगर cap/operations/development cost structure सच में transparently बताया जाता
    तो लोग शायद यह समझ पाते कि “यह तो एक tireless senior engineer रखने” के बराबर स्तर की बात है

• इस email में अगर monthly basis पर यह भी दिखा दिया जाता कि “किन महीनों में limit तक पहुँचे” (Aug 2024, Jan 2025, May 2025 आदि), तो यह बहुत अधिक उपयोगी होता
  मुझे बिल्कुल नहीं पता कि मैं top 5% में हूँ या नहीं
  असल में 1% limit restriction समझ आती है, लेकिन SaaS दुनिया में 5% तो लगभग बहुत सारे वास्तविक users होते हैं

• ऐसी services को metered pricing चाहिए
  सभी AI कंपनियाँ इसी समस्या से जूझ रही हैं
  fixed-cost subscription model इस उम्मीद पर बना है कि user cost की चिंता न करे
  लेकिन बहुत कम संख्या में power users subscription limits को चरम तक धकेल देते हैं
  Terragon जैसी services तो इसी usage को optimize करने के लिए अलग से बनी हैं
  इसके कारण कंपनियाँ limits घटाती रहती हैं, और users उल्टा cost को लेकर और ज़्यादा सचेत हो जाते हैं
  Cursor ने भी कई बार अपनी limits adjust की हैं, और अब Anthropic भी वही कर रहा है
  आखिरकार वे top 10% extreme users को अब subsidize नहीं करना चाहते
  अच्छा होता कि web interface में सीधे metered plan मिलता

  • API मौजूद है, इसलिए आप सीधे token बनाकर Claude Code को बिना किसी अलग plan के इस्तेमाल कर सकते हैं

  • यह 1990s के shared hosting युग की याद दिलाता है

  • अगर metered web plan दिया जाए, तो उन्हें यह भी बताना पड़ेगा कि inference support की असली लागत कितनी महंगी है
    productivity-level के वास्तविक उपयोग पर AI चलाना अभी भी बहुत महँगा काम है

• “Claude को 24/7 background में चलाने वाले advanced use patterns” की वजह से हम अच्छी service का आनंद नहीं ले पा रहे हैं

  • AI services जब विज्ञापन करती हैं, तो कहती हैं “AI खुद काम चलाएगा. developer कॉफी पिए या सोए, काम होता रहेगा”
    तो कुछ developers ने सचमुच उस service का वैध तरीके से ऐसा उपयोग भी किया
    अब बाद में उन्हीं users को समस्या बताना अजीब लगता है

  • वह हिस्सा पढ़कर हँसी आ गई
    ऐसा लगा जैसे कोई ‘सद्भावनापूर्ण विश्व-विनाशक’ ब्रह्मांड की ऊष्मा-मृत्यु को थोड़ा और तेज़ करना चाहता हो

  • मुझे लगता है यह समस्या पहले से अनुमानित थी
    शुरुआती pricing तय करते समय इस पर पर्याप्त विचार हुआ होगा
    बस वे launch को रोकना नहीं चाहते थे, इसलिए लागू करने में देर हुई, और अब इसे वास्तविकता के मुताबिक लागू किया जा रहा है

  • pricing चाहे जैसे तय करो, users अपने plan का 100% इस्तेमाल करना चाहेंगे
    मैं Max subscriber हूँ, फिर भी अक्सर limit से टकराता हूँ
    मैं जितना भुगतान करता हूँ उतना चलाना चाहता हूँ, और उसी पर limit लगना अजीब है

  • यही तो pricing experiment की संरचना है
    जब नियंत्रण ढीला हो, तो कभी-न-कभी extreme users सामने आते हैं, और कंपनी उसे ऐसे पेश करती है जैसे वह टिकाऊ हो, फिर बाद में bonus वापस ले लेती है

• शायद यह थोड़ा अटपटा सुझाव हो, लेकिन मैंने सोचा कि adaptive limits कैसी रहेंगी
  Option 1: शुरुआत में थोड़े समय के लिए burst usage की अनुमति दो, फिर धीरे-धीरे speed कम कर दो, और cooldown के बाद फिर burst करने दो
  इससे user थोड़े समय के लिए productivity को अधिकतम कर सकता है, और servers को भी आराम मिल सकता है
  Option 2: mobile data की तरह, पहले requests fast चलें, फिर बाद में throttling लग जाए, और ज़रूरत हो तो paid top-up खरीदा जा सके
  इससे extra revenue model भी बनता है
  Option 3: infrastructure और network स्तर पर adaptive resource allocation
  जो tasks GPU-intensive नहीं हैं, उन्हें lower priority दो, या network requests को धीरे process करो, या k8s आदि में usage के हिसाब से अलग servers पर tasks बाँटो
  और limits की बहस से अलग, यह भी track करना चाहिए कि सच में कौन-सी requests सबसे ज़्यादा cost पैदा कर रही हैं, ताकि inefficient code paths या infrastructure structure को ठीक करके अतिरिक्त क्षमता निकाली जा सके
  यह भी ज़ोर देकर कहा गया कि छोटे code optimizations भी system में बहुत बड़ी अतिरिक्त गुंजाइश पैदा कर सकते हैं