Anthropic ने बिना पूर्व सूचना Claude Code की usage limit और कड़ी की

• इस हफ्ते की शुरुआत से Anthropic ने Claude Code उपयोगकर्ताओं के लिए बिना किसी पूर्व सूचना के usage limit और कड़ी कर दी है
• खासकर $200 वाले Max प्लान का उपयोग करने वाले heavy users के बीच नाराज़गी तेज़ी से बढ़ी है, और limit पर पहुँचने पर केवल “Claude usage limit reached” संदेश दिखाया जाता है, बिना किसी ठोस विवरण के
• पूर्व सूचना या बदलाव की घोषणा के बिना limit कम हो जाने से, कुछ उपयोगकर्ताओं ने इसे subscription plan downgrade या usage tracking error समझ लिया
• Anthropic ने विस्तृत स्पष्टीकरण के बिना केवल इतना आधिकारिक रूप से कहा कि “कुछ उपयोगकर्ता धीमे responses का अनुभव कर रहे हैं”, लेकिन न सटीक कारण बताया गया और न समाधान की समय-सीमा
• API overload, network errors जैसी समस्याएँ भी साथ में देखी गईं, जिससे असंतोष बढ़ा; उपयोगकर्ता घटते भरोसे के बीच साफ limit policy और बेहतर communication की माँग कर रहे हैं

---

अचानक कड़ी हुई usage limit और बढ़ता भ्रम

• पिछले सोमवार से Claude Code usage limit अचानक कड़ी हो गई, जिससे कई उपयोगकर्ता अनजाने में restriction का शिकार हुए
• केवल “Claude usage limit reached” संदेश दिया गया, और बस यह बताया गया कि कुछ घंटों बाद limit हट सकती है; limit change के बारे में कोई ठोस जानकारी नहीं दी गई
• खासकर $200 Max प्लान जैसे महंगे subscribers के बीच usage tracking errors और plan downgrade को लेकर भ्रम ने अविश्वास को और गहरा किया
• GitHub issue page आदि पर इस तरह की शिकायतें बढ़ीं कि “30 मिनट में कुछ ही requests कीं, फिर भी 900 message limit पार हो गई”, जिससे usage calculation की अपारदर्शिता पर गुस्सा बढ़ा
• एक उपयोगकर्ता ने कहा, “इस limit के साथ project आगे बढ़ाना संभव नहीं है,” और यह भी कि “Gemini या Kimi भी विकल्प नहीं बन पा रहे”

आधिकारिक रुख और network issues

• Anthropic ने केवल इतना कहा कि “कुछ उपयोगकर्ता धीमे responses का अनुभव कर रहे हैं”, और अतिरिक्त विवरण देने से बचा
• इसी अवधि में API overload errors और network outages भी एक साथ हुए, लेकिन official status page पर 100% uptime दिखाया गया, जिससे जानकारी में असंगति दिखी
• limit और available capacity का demand के हिसाब से बदलने वाला अनौपचारिक और परिवर्तनीय ढाँचा भ्रम को और बढ़ाता है

भ्रम बढ़ाने वाली जटिल pricing structure और usage policy

• Anthropic की pricing स्पष्ट usage guarantee के बिना केवल tier-based restrictions और guidance देती है, और Free/Pro/Max सभी में साफ upper limit की जगह “demand के अनुसार बदलती है” जैसी सूचना भ्रम पैदा करती है
  • Max plan: आधिकारिक तौर पर Pro की तुलना में 20 गुना, और Pro को Free की तुलना में 5 गुना अधिक usage limit बताया जाता है, लेकिन absolute usage limits public नहीं हैं
  • Free limit के लिए भी साफ लिखा है कि वह “demand के अनुसार बदलती है”, यानी absolute usage guarantee नहीं है
• उपयोगकर्ताओं का कहना है कि इस बार की limit tightening से पहले वास्तविक service usage (जैसे एक दिन में हज़ार डॉलर से अधिक के API calls) संभव था, इसलिए वे Max plan को अस्थिर और लंबी अवधि में टिकाऊ न रहने वाला model मानते थे
• इसलिए limit कड़ी होने से वे उतने चकित नहीं हुए, लेकिन उनका कहना है कि सबसे बड़ी समस्या transparency की कमी है
  • “कृपया पारदर्शी तरीके से communicate करें. communication की कमी भरोसा तोड़ देती है” जैसी प्रतिक्रिया इसका प्रतिनिधि उदाहरण है

communication और trust crisis की असली जड़

• कुछ उपयोगकर्ताओं ने माना कि Max plan limits लंबे समय तक टिकाऊ न भी हों तो वह समझ में आता है, लेकिन उन्होंने “बस पारदर्शी तरीके से communicate कीजिए” की माँग पर ज़ोर दिया
• बिना सूचना किए गए बदलाव और अस्पष्ट guidance उपयोगकर्ताओं के भरोसे को कम करते हैं
• साफ limit guidance, पहले से communication, और issues पर तेज़ response सेवा को बनाए रखने और ग्राहक भरोसा जीतने के लिए बेहद महत्वपूर्ण हैं

[princox]

लगता है कि यह agentic coding के अग्रिम मोर्चे पर मौजूद प्रोडक्ट है, इसलिए इस पर काफ़ी ज़्यादा ट्रैफ़िक उमड़ रहा है..

[GN⁺]

Hacker News राय

• एक उपयोगकर्ता ने गुमनाम रहने का अनुरोध करते हुए कहा कि उपयोग-सीमा लगने के बाद वह अपना प्रोजेक्ट आगे नहीं बढ़ा सका। ऐसा लगा जैसे vibe की सीमा आ गई हो, और अब खुद सोचने का समय है

  • बात सही है, लेकिन इन कंपनियों की बिक्री का मूल आधार यही है कि 'सोचने' का एक बड़ा हिस्सा आउटसोर्स किया जा सकता है, और AI से जुड़ा निवेश भी काफी हद तक इसी आधार पर टिका है। इतना पैसा झोंकने के बाद भी अगर बाज़ार वैसा का वैसा है, तो यह थोड़ा अजीब लगता है
  • शायद बात सिर्फ थोड़ा सोचने पर खत्म नहीं होगी। प्रोजेक्ट जारी रखने के लिए कहीं ज्यादा गहरी सोच, शायद चरम स्तर की सोच-समझ की ज़रूरत पड़ेगी
  • यह कैसी व्यंग्यात्मक विडंबना है कि किसी ने कैसे अनुमान लगा लिया होगा कि किसी third-party service पर, जिसकी लंबी अवधि की उपलब्धता स्पष्ट नहीं है, इतनी मज़बूत निर्भरता रखना समस्या बन सकता है। यह मानो paid compiler या remote mainframe के ज़माने में लौटने जैसा है, और लोग बार-बार यही गलती दोहराते हैं
  • मुझे 99% यक़ीन है कि ये उपयोगकर्ता ऐसे vibe coder नहीं हैं जिन्हें coding ही नहीं आती। ऐसे लोग terminal tool छूने के बजाय lovable जैसे टूल इस्तेमाल करेंगे
  • मैं भी उसी उद्धरण पर टिप्पणी करने आया था। हैरानी की बात है कि हम इस स्थिति तक इतनी जल्दी पहुँच गए, लेकिन दूसरी तरफ़ यह बिल्कुल अप्रत्याशित भी नहीं है

• Claude 4.0 को अगर कच्ची बुद्धिमत्ता के लिहाज़ से देखें, तो वह दूसरे प्रमुख models से ज़्यादा स्मार्ट नहीं कहा जा सकता। लेकिन coding के दौरान सही tools के इस्तेमाल के लिए इसे बेहद अच्छी तरह तराशा गया है। अगर दूसरे models भी जल्दी पकड़ बना लें, तो इस तरह कड़ी पाबंदी लगाना मुश्किल होगा। Google की स्थिति अलग है, क्योंकि वह खुद silicon deploy करता है और optimization भी करता है, इसलिए absolute cash flow के लिहाज़ से मज़बूत जगह पर है। दिलचस्प बात यह है कि यहाँ टिप्पणियों में compute scaling laws को समझने वाले लोग लगभग दिख ही नहीं रहे। लोगों के दिमाग़ में Uber मॉडल जैसा विचार बैठा हुआ है कि किसी बिंदु पर सिस्टम को कीमत बढ़ानी ही पड़ेगी, लेकिन AI इंसानी श्रम नहीं है। समय के साथ computing cost घटनी ही है। short term में घाटा सहकर दांव लगाना ही शायद सबसे अधिक संभावना वाली रणनीति है, और मुझे नहीं लगता कि यह कोई बेवकूफ़ी है। बहुत से लोग इस bubble के फूटने का इंतज़ार कर रहे हैं ताकि बाद में कह सकें, "मैंने पहले ही कहा था", लेकिन लंबी अवधि में दिशा यही सही है

  • मान लें कि Moore's law लागू भी रहता है, तब भी यह इस धारणा पर आधारित है कि computer resources की efficiency नहीं बदलती और प्रति computation बिजली की efficiency भी वैसी ही रहती है; ऐसे में compute cost हर 18 महीने में सिर्फ आधी होगी। असल टिप्पणी में कहा गया था कि $200/माह प्लान पर खर्च $4000 तक पहुँच गया, तो cost efficiency के हिसाब से इसकी बराबरी में 8 साल लगेंगे। सवाल यह है कि क्या वे 8 साल तक घाटा सहने को तैयार हैं
  • सच कहें तो मौजूदा models उतने ‘स्मार्ट’ भी नहीं हैं जितना वे दावा करते हैं। AGI से तो वे अभी बहुत दूर हैं। context management, task separation, retries, infinite loop रोकना, सही tool exposure जैसी चीज़ें ज़्यादा महत्वपूर्ण हैं
  • मैं $100/माह वाला प्लान नहीं लेता, बल्कि API दरों के हिसाब से भुगतान करता हूँ और Claude Code बहुत सावधानी से इस्तेमाल करता हूँ। पहले ही दिन यह loop में फँस गया और वही दो गलत solutions दोहराते-दोहराते $30 उड़ा दिए, तब जाकर रुका। उसके बाद से मैं रोज़ $3~$5 खर्च करके काफी कुशलता से बहुत कुछ हासिल कर रहा हूँ। Anthropic को ऐसा तरीका खोजना चाहिए जिससे developers, Claude Code को और समझदारी से इस्तेमाल करें। अगर नियंत्रण न रहे तो यह सचमुच बेकाबू होकर भागता है
  • model की समस्या यह है कि बेकार content की बाढ़ आ जाती है। जब industry छोटे पैमाने पर हो तो इतना pollution शायद समस्या न हो, लेकिन global scale पर जाने पर उसकी सफ़ाई आसान नहीं होगी
  • Claude ठीक है, लेकिन अगर ‘smartness’ चाहिए तो बात अलग है। व्यक्तिगत रूप से मुझे लगता है कि Mistral के medium 3 या devstral medium models को कम आंका जाता है। दोनों ‘स्मार्ट’ नहीं हैं, लेकिन साधारण कामों के लिए कामचलाऊ code चाहिए तो price-to-performance के लिहाज़ से बहुत अच्छे हैं

• मैंने Claude Code को $20/माह वाले बेसिक प्लान पर side project में इस्तेमाल किया। मैंने अपना पूरा कामकाजी समय भी इसमें नहीं लगाया, फिर भी call volume काफी था। मुझे लगा था कि $20 की सीमा जल्दी छू लूँगा, लेकिन अंत तक नहीं पहुँचा। सच कहूँ तो AI जिन हिस्सों में काम नहीं कर पाता था, वहाँ मुझे खुद ठीक करना या हाथ से काफी coding करनी पड़ती थी, लेकिन token usage सचमुच बहुत उदार लगा। API pricing से तुलना करूँ तो ऐसा लगता था जैसे रोज़ $10~$20 के tokens इस्तेमाल कर रहा हूँ। शायद कुछ समय तक users जोड़ने के लिए limits बहुत खुली रखी गई थीं, और अब capacity संभालना मुश्किल हो रहा है इसलिए उन्हें कसा जा रहा है। लेख में जैसा कहा गया, $200/माह प्लान की सीमा पार करने लायक coding करने के लिए कितना ज़्यादा इस्तेमाल करना पड़ेगा, इसकी कल्पना करना भी मुश्किल है

  • Claude Code में tokens को efficient तरीके से इस्तेमाल करने के बहुत सारे तरीके हैं। मेरा सावधान अनुमान है कि जल्द ही Claude Code के लिए कोई dedicated model आ सकता है। मेरे प्रयोग के अनुभव में, बहुत से tokens इस वजह से बर्बाद होते हैं कि जैसे पूरा Python script दोबारा पढ़कर comment status जाँचना, या R script फिर से पढ़कर सिर्फ bracket बंद हुए हैं या नहीं यह देखना—ऐसी अर्थहीन पुनरावृत्ति। सिर्फ ऐसे inefficient patterns पकड़ लिए जाएँ, तो काफी resources बच सकते हैं
  • आजकल ऐसी limits बहुत तेज़ी से बदलती हैं, कभी-कभी हफ्ते या कुछ दिनों के भीतर, और time zone, location, account बनने की तारीख़ जैसी चीज़ों के हिसाब से भी अलग होती हैं
  • मैं CC में सिर्फ एक request से एक घंटे के भीतर limit तक पहुँच गया था। वह opus भी नहीं था। कुछ समय इस्तेमाल करने पर कभी-कभी लगभग preemptive warning message भी दिखता है, लेकिन अफ़सोस इस बात का है कि limits साफ़-साफ़ बताने के बजाय जैसे बस higher plan upsell करने की कोशिश हो रही हो
  • सोचने की प्रक्रिया (Thiking) सामान्य Chat की तुलना में कहीं ज़्यादा inefficient है। ज़्यादा इस्तेमाल करो तो जल्दी ही सैकड़ों डॉलर खर्च हो सकते हैं
  • अगर आप limit तक नहीं पहुँच पा रहे, तो शायद इसका मतलब है कि prompts को और रचनात्मक ढंग से लिखने की ज़रूरत है। मैं कभी-कभी एक prompt देकर उसे लगभग एक घंटे तक स्वतंत्र रूप से काम करने देता हूँ और इस तरह limit तक पहुँचा देता हूँ। sub-agents बनाकर parallel में चलाया जा सकता है, या पूरी तरह automation के साथ लंबे समय तक काम कराया जा सकता है। 'यह एक काम कर दो' से थोड़ा व्यापक नज़रिया रखना उपयोगी है

• अगर Apple ने M4 MacBook खरीदे लोगों की performance बिना किसी चेतावनी के M1 के स्तर तक घटा दी होती, तो tech media और consumer groups दोनों में हंगामा मच जाता। लेकिन AI कंपनियाँ $100 लेकर access बेचती हैं और फिर बिना कुछ कहे performance गिरा देती हैं, तब भी सन्नाटा रहता है। समझ नहीं आता यह कैसे संभव है

  • कंपनी के नज़रिए से capacity सीमित है, इसलिए वह सभी users को एक तर्कसंगत product देना चाहती है। लगता है उचित limits तय करना और उनका पालन कराना बेहद कठिन साबित हुआ है। शायद उन्हें वास्तविक capacity या भाग लेने वाले users की संख्या का अनुमान लगाने में दिक्कत हो रही है। अभी competitors भी बहुत नहीं हैं, और pricing के लिए कोई खास benchmark भी नहीं है। उम्मीद है आगे स्थिति बेहतर होगी

• शायद अभी वे घाटे में ऑपरेट कर रहे हैं, इसलिए गुस्सा होने का समय नहीं है। Cursor की pricing भी इसी तरह अपारदर्शी है। मैं Max plan के लिए भुगतान कर रहा हूँ, लेकिन API report के हिसाब से अब तक लगभग $1,000 के बराबर इस्तेमाल कर चुका हूँ। कितना quota बचा है, यह भी नहीं पता, और API जो pricing info देता है वह भी समझ में नहीं आती

  • मेरा एक सहकर्मी दावा करता है कि उसने इस महीने प्रति सप्ताह $1,000 उड़ा दिए। कंपनी के नज़रिए से देखें तो उसे सिर्फ $200/माह subscription देना है, यह सचमुच चौंकाने वाला है
  • हमने कल ही closed alpha खत्म किया है और अब optimal pricing policy पर विचार कर रहे हैं। अगर आप feedback दे सकें, तो https://www.charlielabs.ai/pricing देखना हमारे लिए बहुत मददगार होगा
  • यह जानने की उत्सुकता है कि आप pricing देखने के लिए कौन-सा tooling इस्तेमाल कर रहे हैं। पूछना चाहता हूँ कि क्या वह cursor-stats है
  • मैं इस बात से सहमत नहीं हूँ कि सिर्फ इसलिए नरमी बरतनी चाहिए कि वे घाटे में ऑपरेट कर रहे हैं। आजकल साफ़ revenue model के बिना launch करने की कोशिश करने वाले products से मैं सचमुच ऊब गया हूँ

• मैं उन वास्तविक workflows का वीडियो देखना चाहता हूँ जिनमें लोग रोज़मर्रा में limit तक पहुँच जाते हैं। मैं खुद coding के लिए ज़्यादातर sonnet इस्तेमाल करता हूँ, लेकिन $20/माह प्लान पर basic limit तक भी नहीं पहुँचा। इसका उपयोग specs लिखने, documentation, प्रसिद्ध examples के आधार पर दोहराए जाने वाले काम, और किसी खास service को बार-बार बनाने जैसे कामों में करता हूँ। अगर पूरी codebase rewrite नहीं करनी, तो क्या छोटे fixes में अंग्रेज़ी में समस्या समझाकर AI को सौंपने और एक बड़ा cycle चलाने से बेहतर यह नहीं होता कि मैं खुद ही जल्दी ठीक कर दूँ?

  • मैं Opus और लंबे workflows के साथ limit तक पहुँच जाता हूँ। खास तौर पर दो बड़े workflows में बाँटकर—plan और implementation—सिर्फ idea research और plan document बनाने में ही $10~$30 का API cost लग जाता है। review करते समय छोटी गलतियाँ या अनावश्यक बातें मैं खुद सुधार देता हूँ, और अगले चरण में implementation भी आगे बढ़ाता हूँ। implementation चरण अपेक्षाकृत सस्ता पड़ता है। इसी plan document के आधार पर मैं अपने-आप GitHub PR भी generate करा देता हूँ। $100 Max plan की rate limit तक पहुँचने के लिए, 5 घंटे के भीतर इस cycle को 3~4 बार दोहराना ही काफी है। Opus को जटिल निर्देश सीधे दे देना भी संभव है, इसलिए भरोसे का स्तर काफ़ी ऊँचा है। अगर Code को सिर्फ साधारण interaction की तरह इस्तेमाल करो, तो लगभग कभी limit तक नहीं पहुँचोगे। लगता है ज़्यादातर vibe coder ही यह सीमा बार-बार छूते हैं
  • जब AI सही दिशा में converge नहीं कर पाता, तो अंततः इंसान को खुद आकर काम पूरा करना ही पड़ता है
  • जानना चाहता हूँ कि क्या आप Claude Code को sonnet के साथ इस्तेमाल कर रहे हैं। अगर सिर्फ web पर इस्तेमाल करें, तो limits बहुत ढीली लगती हैं
  • इस हफ्ते तो Max plan होने के बावजूद साधारण काम भी सफलतापूर्वक नहीं हो रहे। यह सिर्फ Max users पर overload की बात नहीं है। ऐसा लगता है जैसे कभी भी मनमाने ढंग से rate limit लग जाती है। कभी तो पहला prompt भी अटक जाता है
  • कुल मिलाकर इंसान के लिए खुद करना तेज़ होता है, लेकिन मैं interrupt-driven तरीके से कई tasks के बीच आता-जाता रहता हूँ, इसलिए बस जल्दी से prompt डाल देता हूँ और फिर background में उसे काम करने देता हूँ। agent भले 3 गुना ज़्यादा समय ले, मेरी अपनी time cost सिर्फ कुछ सेकंड की prompt typing तक सीमित रहती है

• कुछ दिन पहले मैं दो projects में बड़े पैमाने का refactoring कर रहा था और साथ ही दो दूसरे projects का design work भी चला रहा था। Gemini API usage देखा तो पता चला कि एक ही दिन में $200 खर्च हो चुके थे। users इससे भी कहीं अधिक intensity पर चला सकते हैं। $200/माह unlimited policy से कंपनी के लिए मुनाफ़ा निकालना मुश्किल होगा। आगे शायद ऐसे systems बनेंगे जो cost को ध्यान में रखकर काम को बुद्धिमानी से बाँटें। लगता है openrouter भी इसी दिशा में बढ़ रहा है, लेकिन सही routing करने के लिए बहुत विशाल context information चाहिए होगी

• usage limit लगने के बाद किसी ने कहा, "सचमुच अब project आगे नहीं बढ़ता।" उसने Gemini, Kimi आदि भी इस्तेमाल किए, लेकिन Claude Code जितना विविध feature set किसी और tool में नहीं मिला। इसे PMF (product-market fit) कहा गया

• मैंने इस हफ्ते $200/माह प्लान शुरू किया, जबकि पहले से हर महीने API tokens पर $300+ खर्च कर रहा था। मैंने सोचा भी कि 'Anthropic के लिए इसमें हिसाब कैसे बैठता होगा?' लेकिन API overload errors लगातार आते रहे, इसलिए आखिरकार प्लान cancel करके फिर API tokens पर लौट गया। समझ नहीं आता ऐसी policy का उद्देश्य क्या है, लेकिन मैं तो पैसे देकर भी इस्तेमाल करने को तैयार हूँ। बस $200/माह का नारा लगाने के बजाय ठीक से access guarantee कर दें तो बेहतर होगा

  • जानना चाहता हूँ कि क्या यह अनुभव Opus के साथ था। और यह भी कि आप किस तरह का काम कर रहे थे। मैंने सिर्फ 2.5MB के बड़े source file पर काम करते समय tokens बहुत ज़्यादा खर्च होते देखे हैं। इसके अलावा मैं 100EUR प्लान भी पूरा इस्तेमाल नहीं कर पाता। मैं ज़्यादातर Opus ही इस्तेमाल करता हूँ
  • कहीं ऐसा तो नहीं कि API unit pricing शुरू से ही वास्तविक लागत की तुलना में बहुत ऊँची रखी गई हो। मैंने तो बस $5 recharge करके थोड़ा परीक्षण किया, और लगभग 30 मिनट की computation चली, जो अनुभव में लगभग 3 घंटे के इस्तेमाल के बराबर लगी। मोटे तौर पर $10/घंटा मानें तो सालाना $90,000 बैठता है। अभी तक मुझे भरोसा नहीं कि GPU खरीदने और चलाने की लागत सचमुच इतनी, यानी साल के 90 हज़ार डॉलर, पड़ती होगी। अभी भी यह मानना कठिन लगता है कि GPU infrastructure cost सिर्फ hardware investment के स्तर से बहुत आगे जा सकती है

• समझ नहीं आता कि service quality जानबूझकर घटाई गई है, या demand इतनी तेज़ी से बढ़ी कि servers संभाल नहीं पा रहे और इसलिए अस्थायी तौर पर limits घटाई गईं। अगर demand इसी तरह बढ़ती रही, तो ये restrictions स्थायी रूप से और कड़ी हो सकती हैं। मुझे नहीं लगता कि Anthropic ने इसी समय COGS optimization करने का फ़ैसला लिया होगा। उसके पास पूरे DevTools market पर कब्ज़ा करने का मौका है, cash भी है और invest करने की इच्छा भी मज़बूत है; ऐसे में product power कमज़ोर करना बहुत short-term सोच लगेगा

  • बहुत से users ने Cursor को बहुत जल्दी छोड़ दिया। मेरे लिए IDE बदलना बड़ी बात है, इसलिए मैंने Cursor को कभी आज़माया ही नहीं। Claude Code कहीं बेहतर concept है और इसका IDE से जुड़ा होना ज़रूरी भी नहीं है। इसलिए प्रतिस्पर्धी सेवा पर switch करना उल्टा और आसान हो सकता है। इस नज़रिए से देखें तो Claude Code की model-आधारित प्रकृति में यह जोखिम भी है कि market share हासिल करना ही बेअर्थ हो जाए।