Claude Code Pro Max 5x प्लान में सामान्य उपयोग पर भी 1.5 घंटे में quota खत्म होने की समस्या

• Pro Max 5x(1M context) प्लान में सामान्य स्तर के Q&A और development काम से भी 1.5 घंटे में token limit पार होने की समस्या सामने आई
• कारण के तौर पर cache_read token को पूरे अनुपात (1.0x) से गिने जाने वाली गड़बड़ी की ओर इशारा किया गया, जिससे caching का असर खत्म होकर consumption तेज हो जाता है
• background session के automatic calls, automatic compaction(auto-compact), और बड़े context input मिलकर consumption speed को और बढ़ाते हैं
• कम्युनिटी ने cache TTL में कमी (1 घंटा→5 मिनट) और cache invalidation(cache busting) को मुख्य कारण के रूप में विश्लेषित किया
• Anthropic default context reduction(400k), UX improvements, और inactive call optimization पर काम कर रहा है और user feedback इकट्ठा कर रहा है

---

Pro Max 5x प्लान में quota के तेज़ी से खत्म होने की समस्या

• Pro Max 5x(claude-opus-4-6, 1M context) प्लान में मध्यम स्तर के Q&A और हल्के development से भी 1.5 घंटे में quota खत्म होने की घटना रिपोर्ट हुई
  • इससे पहले 5 घंटे के high-intensity development में consumption सामान्य था, लेकिन reset के बाद तेज़ consumption शुरू हो गया
  • environment था Claude Code CLI on WSL2, और यह एक single session (2 बार auto-compact) में हुआ
• cache_read token को पूरे अनुपात (1.0x) से गिने जाने वाली गड़बड़ी को मुख्य कारण माना गया
  • सामान्य स्थिति में cache_read को 1/10 अनुपात से गिना जाना चाहिए; ऐसा न होने पर caching का लाभ खत्म हो जाता है
  • session log(~/.claude/projects/.../*.jsonl) के usage object के जरिए token usage का विश्लेषण किया गया
• background session के automatic calls, auto-compact की high-cost processing, और 1M context window के बड़े input मिलकर consumption speed को तेज़ करते हैं
• कम्युनिटी विश्लेषण के अनुसार, कुछ users ने cache TTL में कमी (1 घंटा→5 मिनट) और cache invalidation(cache busting) को मुख्य कारण बताया
• Anthropic टीम default context reduction(400k), UX improvements, और inactive call optimization पर काम कर रही है, और user feedback के जरिए अतिरिक्त data इकट्ठा करने का अनुरोध कर रही है

मापा गया token consumption

• विंडो 1 (15:00–20:00, 5 घंटे, high-intensity development)

  • API calls 2,715, Cache read 1,044M, Cache create 16.8M, output 1.15M token
  • प्रभावी input (1/10 अनुपात लागू होने पर) 121.8M token
  • Express server + iOS app implementation, graphify pipeline, SPEC-आधारित multi-agent coordination किया गया

• विंडो 2 (20:00–21:30, 1.5 घंटे, मध्यम स्तर का उपयोग)

  • main session(vibehq): API 222 बार, Cache read 23.2M, Cache create 1.4M, output 91k
  • background session(token-analysis, career-ops सहित): कुल 691 calls, Cache read 103.9M, output 387k
  • कुल 13.1M प्रभावी token (1/10 अनुपात लागू होने पर) → सामान्य स्थिति में quota over नहीं होना चाहिए
  • वास्तव में 105.7M token (1.0x calculation पर) → प्रति घंटे 70.5M के स्तर पर, जो quota खत्म होने से मेल खाता है

मुख्य समस्या सारांश

• 1. Cache read token की billing limit calculation में गड़बड़ी

  • अपेक्षा: cache_read को 1/10 अनुपात से गिना जाए
  • वास्तविकता: पूरे अनुपात से गिना गया, जिससे caching effect निष्प्रभावी हो गया
  • 1M context environment में प्रति call 100~960k token भेजे गए, इसलिए 200 से अधिक calls पर कुछ ही मिनटों में quota खत्म हो सकता है

• 2. Background session द्वारा shared quota consumption

  • inactive session(token-analysis, career-ops आदि) भी auto-compact और post-processing calls के जरिए shared quota लगातार consume करते हैं

• 3. auto-compact के high-cost calls

  • compact करने से पहले पूरा context(~966k token) cache_creation के रूप में भेजा जाता है, जिससे सबसे महंगा call अपने-आप होता है

• 4. 1M context window के side effects

  • बड़ा context प्रति call token count को बहुत बढ़ा देता है, जिससे quota consumption speed तेज़ हो जाती है

पुनरुत्पादन प्रक्रिया

1. Pro Max 5x प्लान में Opus model के साथ Claude Code चलाएँ
2. ~/.claude/rules/ में लगभग 30 rule files (19k token overhead) शामिल करें
3. file reading, build, test जैसे tool-केंद्रित काम करें
4. /context command से context के बढ़ने की पुष्टि करें
5. 200~300 calls के बाद quota में तेज़ गिरावट की पुष्टि करें
6. दूसरे terminal में 2~3 session चालू रखें
7. reset के बाद भी कम समय में quota खत्म होने की पुष्टि करें

अपेक्षित व्यवहार और वास्तविक व्यवहार की तुलना

• अपेक्षित:

  • cache_read को 1/10 अनुपात से गिना जाए
  • inactive session का consumption न्यूनतम हो
  • auto-compact अत्यधिक consumption न कराए
  • मध्यम उपयोग पर 2~3 घंटे तक चलना चाहिए

• वास्तविक:

  • 1.5 घंटे में खत्म
  • background session ने 78% consumption किया
  • कुल 105.7M token transfer से अनुमान है कि cache_read को पूरे अनुपात से गिना गया

सुधार के सुझाव

1. cache_read calculation method को स्पष्ट किया जाए — documentation में वास्तविक billing limit ratio स्पष्ट रूप से लिखा जाए
2. effective token आधारित limit — cache_read को 1/10 अनुपात से गिने जाने के लिए सुधार किया जाए
3. session idle detection — inactive session के automatic calls रोके जाएँ या warning दिखाई जाए
4. real-time token consumption visibility — cache_read, cache_create, input और output के अनुसार usage दिखाया जाए
5. context-आधारित cost prediction — काम शुरू करने से पहले अनुमानित token cost दिखाई जाए

कम्युनिटी विश्लेषण और चर्चा

• cnighswonger

  • claude-code-cache-fix interceptor के जरिए 24 घंटे में 1,500 calls का data इकट्ठा किया
  • तीन hypotheses(cache_read 0.0x, 0.1x, 1.0x) की जांच में केवल 0.0x model ने 5 घंटे की window में consistent result(CV 34.4%) दिखाया
  • निष्कर्ष: cache_read का वास्तव में quota पर लगभग कोई असर नहीं, cache सामान्य रूप से काम कर रहा है
  • हालांकि, single-account data होने के कारण अतिरिक्त verification की जरूरत है

• henu-wang

  • cache TTL के 1 घंटे से 5 मिनट तक घट जाने वाली regression के बाद, session pause होते ही cache_create होने लगा, जिससे 12.5 गुना अधिक cost आई
  • context जितना लंबा होता है, cost उतनी ही non-linear तरीके से बढ़ती है
  • अस्थायी समाधान के तौर पर short session रखना, /compact command का सक्रिय उपयोग, और CLAUDE.md में core context को पहले से लोड करना सुझाया गया

• bcherny (Anthropic टीम)

  • 1M context window के उपयोग में prompt cache miss का high cost होने की बात मानी
  • UX improvements (long session resume पर /clear सुझाना) और default context को 400k तक घटाने का प्रयोग चल रहा है
  • multi-agent और plugin उपयोग में inactive कामों द्वारा token over-consumption के मामले पहचाने गए, और automatic cleanup तथा scheduling improvements पर काम हो रहा है

• wadabum

  • नए session में cache बिल्कुल hit न होने वाले bug(#47098, #47107) की ओर ध्यान दिलाया
  • git status-आधारित system prompt और CLAUDE.md block हर session में बदलने से cache invalidation(cache busting) होता है
  • cnighswonger ने जवाब दिया कि interceptor कुछ sorting stabilization करता है, लेकिन git-status समस्या के लिए अलग fix की जरूरत है

कम्युनिटी सुझाव सारांश

• RockyMM: session limit पर पहुँचने पर auto-summary के बाद resume का मार्गदर्शन हो, और TTL को 10 मिनट किया जाए
• mikebutash: Pro प्लान में 5 घंटे में केवल 2 prompts संभव होने की बात कही, और v2.1.81 पर rollback तथा cache-fix install से 3~4 गुना सुधार की पुष्टि की
• wutlu: काम के अनुसार session reset करके समस्या कम की
• dprkh: debug mode skill(Skill.md) साझा कर कारण पता लगाने में मदद की

निष्कर्ष

• Pro Max 5x प्लान में quota के तेज़ी से खत्म होने की समस्या cache behavior, TTL regression, context inflation, और background calls के संयुक्त प्रभाव से जुड़ी पाई गई
• कम्युनिटी का विश्लेषण है कि cache_read calculation bug से अधिक, cache invalidation और TTL reduction मुख्य कारण हैं
• Anthropic टीम default context reduction, cache UX improvement, और inactive call optimization पर काम कर रही है, और user feedback(/feedback) के जरिए अतिरिक्त data इकट्ठा करने का अनुरोध कर रही है

[kimjoin2]

क्वालिटी के हिसाब से इसका कोई असली विकल्प नहीं है
और अगर किसी आसान patch से इसे थोड़ा और इस्तेमाल किया जा सके तो अच्छा होगा।

[GN⁺]

Hacker News की राय

• मैं Claude Code टीम का Boris हूँ। हाल में रिपोर्ट की गई समस्याओं की जाँच के बाद, मुख्य कारण दो निकले

  1. 1M token context window इस्तेमाल करने पर prompt cache miss महँगा पड़ता है। अभी cache TTL 1 घंटा है, इसलिए अगर आप एक घंटे से ज़्यादा देर के लिए उठ जाते हैं, तो session expire हो जाता है और पूरा cache फिर से लोड करना पड़ता है। इसे बेहतर बनाने के लिए UX सुधार जारी किए गए हैं, और default को 400k तक घटाने वाले विकल्प पर विचार हो रहा है। अगर अभी टेस्ट करना हो, तो CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude कमांड इस्तेमाल करें
  2. बहुत ज़्यादा plugins या agents एक साथ चलाने पर token की बर्बादी होती है। इसे हल करने के लिए UX सुधार, और गैर-प्रमुख tasks की automatic cleanup व scheduling पर काम चल रहा है
     जिन users को यह समस्या आ रही है, वे /feedback कमांड से feedback भेजें, इससे debugging में मदद मिलेगी
  • Boris, अभी community में जो user अनुभव पोस्ट हो रहे हैं, वे सिर्फ साधारण exceptions नहीं हैं। Jeff Bezos ने जैसा कहा था, कभी-कभी किस्से ही सच बताते हैं, डेटा नहीं। आपको गंभीरता से देखना चाहिए कि कहीं metrics ही गलत तो नहीं हैं
  • मैं सोच रहा था कि अचानक यह समस्या क्यों आई, लेकिन जाँच में पता चला कि prompt cache TTL 1 घंटे से घटाकर 5 मिनट कर दिया गया था। नया session शुरू करने पर भी आखिर में सब कुछ फिर से build करना पड़ता है, इसलिए यह अक्षम है। cache expiry पर नज़र रखनी पड़े, ऐसा ढाँचा CC की philosophy के खिलाफ है
  • मेरे मामले में सबसे गंभीर regression यह था कि system prompt हर बार files को malware scan करने की कोशिश कर रहा था। इससे token बहुत तेज़ी से खर्च हुए, और लगातार “not a malware” जवाब आता रहा। यह design फैसला गलत था। आखिरकार मैंने project छोड़ दिया और Qwen पर चला गया, जो काफ़ी अच्छा निकला
  • /clear नोटिस कोई समाधान नहीं है। cache साफ़ करने पर आखिर फिर से build करना ही पड़ता है, इसलिए cost वही रहती है। UX के ज़रिए users को छोटे context की तरफ धकेलना service quality गिराना है। अगर दिक्कत cost की है, तो pricing या architecture ठीक करनी चाहिए
  • OpenAI में समस्या होने पर usage limit reset कर दी जाती थी, लेकिन Anthropic ऐसा कुछ नहीं कर रहा। इस बार तो यह जानबूझकर किया हुआ लग रहा है

• हाल में Claude साफ़ तौर पर धीमा और अक्षम हो गया था। files बताने पर भी वह 5 मिनट से ज़्यादा exploration loop में फँसा रहता था, और session limit जल्दी आ जाती थी। दिन में सिर्फ तीन बार इस्तेमाल करने पर weekly limit का 25% खत्म हो जाता था। इसलिए मैं $100 वाले Codex plan पर चला गया, और accuracy व उदारता दोनों में वह कहीं बेहतर है। हाँ, Codex का बोलने का अंदाज़ थोड़ा खटकता है, इसलिए मैंने Agents.md में अलग से instructions जोड़ दिए। UI की feeling पहले वाले Claude Code में बेहतर थी, लेकिन backend debugging और जटिल समस्या-समाधान में Codex आगे है। अभी तो मैं Codex और Cursor के $20 plans की तुलना करने की सलाह दूँगा

  • मेरा अनुभव भी ऐसा ही था। कुछ दिन पहले Claude ऐसे लग रहा था जैसे रुक गया हो और बस सोचता ही रहे, लेकिन अगले दिन फिर सामान्य चलने लगा
  • मैं Codex Business plan (30 euro) इस्तेमाल कर रहा हूँ, और हाल में quota कम हुआ है ऐसा महसूस हो रहा है। फिर भी Claude Code की तुलना में शर्तें अब भी बहुत बेहतर हैं
  • मैं अभी Opus, Haiku, Sonnet models में confidence score के व्यवहार की तुलना कर रहा हूँ। मध्यम कठिनाई वाले tasks में Opus सबसे कुशल है
  • मैंने CC, Gemini-cli, और Codex इस्तेमाल किए हैं, और CC अब भी सबसे बेहतरीन है। Cursor या Aider का संयोजन इससे बेहतर है या नहीं, यह जानना चाहता हूँ
  • AI coding में context की बर्बादी बहुत होती है, इसलिए custom sandbox से scope सीमित किया जाए तो efficiency बढ़ती है

• issues को देखते हुए समझ आता है कि Anthropic tickets जल्दी क्यों बंद करता है। ज़्यादातर AI-जनरेटेड noise लगते हैं। मेरा समाधान यह रहा

  1. हर session में max thinking चालू रखा, ताकि बेकार के path exploration कम हों
  2. session को लगातार active रखा। अगर cache 5 मिनट में expire हो जाए, तो tokens फिर से build करने पड़ते हैं
  3. 200k tokens के बाद तुरंत compact चलाया
     Anthropic का जबरन 1M model लागू करना मुझे सबसे ज़्यादा खलता है
  • issue देखकर मैं भी हँसा था। शायद Claude Code से ही कहा गया होगा, “जाकर पता करो token क्यों खत्म हो गए”
  • कोई कहता है thinking चालू करो, कोई कहता है बंद करो। दोनों ही token बचत बताते हैं, यह विडंबनापूर्ण है
  • असली समस्या cache का random invalidation bug है। लगता है API client subscriber cache को समय से पहले खत्म कर देता है। ऊपर से input token cost भी चुपचाप बढ़ा दी गई
  • मैंने भी इसकी पुष्टि की है। max effort मदद करता है। context को 25% से नीचे रखना ज़रूरी है। सोच रहा हूँ कि cache expiry status देखने का कोई तरीका है या नहीं
  • /model opus या /model sonnet कमांड से 1M model बंद किया जा सकता है

• अब लग रहा है कि subsidy के दौर का अंत आ रहा है। Google Gemini community में भी हाल में quota कटौती को लेकर शिकायतों की बाढ़ है (issue link)। मैं भी आखिरकार Kiro IDE और Codex CLI के संयोजन पर चला गया और संतुष्ट हूँ

  • इस तरह का बदलाव पहले से अनुमानित था। free token के दौर में ज़रूरी libraries पहले से तैयार कर लेना समझदारी भरी रणनीति थी
  • Anthropic अब enterprise ग्राहकों पर केंद्रित हो रहा है, और OpenAI भी कुछ वैसी ही राह पर है। Reddit और Discord पर open models या Chinese alternatives खोजने की कोशिशें दिख रही हैं, लेकिन अभी पूरा विकल्प नहीं है
  • antigravity pro quota जल्दी खत्म करता है, लेकिन flash mode कहीं ज़्यादा उदार है। STM32 project पर काम करते हुए मुझे 3 गुना तेज़ productivity मिली
  • आखिर इस प्रवृत्ति का अंत शायद output पर ads लगने वाले दौर में हो सकता है
  • इससे मुझे पुराने $3 Uber rides याद आ गए

• मूल कारण की तरफ इशारा करने वाला issue “Not planned” के रूप में बंद किया जाना चिंताजनक है

  • जवाब की भाषा AI-लिखी हुई जैसी अस्वाभाविक लगती है। “1 घंटे का TTL ज़्यादा महँगा है” वाला तर्क भी अजीब है। अगर वजह cost है, तो toggle न देने की बात मानना मुश्किल है
  • इतना डरने की ज़रूरत नहीं। quality खराब हो जाए तो बस इस्तेमाल बंद कर दो
  • मुझे लगता है Anthropic casino की तरह tokens बेच रहा है, और users पैसे हारें तो उसे परवाह नहीं। अगर ऐसा मॉडल पसंद नहीं, तो local LLM इस्तेमाल करना बेहतर होगा

• version 2.1.34 पर rollback करने के बाद quota और cache की ज़्यादातर समस्याएँ हल हो गईं।
  ~/.claude/settings.json में "effortLevel": "high", "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1 वगैरह जोड़ दिए, और बाकी versions हटा दिए।
  Adaptive thinking अभी अधूरा है, लेकिन आगे सुधरे तो मददगार हो सकता है। फिर भी Codex पर जाने का सोच रहा हूँ

  • मैंने भी ~/.bashrc में CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000, DISABLE_AUTOUPDATER=1 वगैरह सेट कर रखा है

• छोटे models में भी ऐसी ही समस्या थी। मेरा मानना है कि निष्पक्ष लेन-देन पारदर्शी माप से शुरू होता है। मैं इस महीने की subscription रद्द करने वाला हूँ

  • कुछ मामलों में computer sleep mode में होने पर भी session शुरू हो जाता था और tokens खर्च हो जाते थे। “अभी कितना समय हुआ है?” जैसे साधारण सवाल में भी 10% चला जाता था

• इस साल मैंने tax filing पर AI agents का प्रयोग किया। Opus 4.6, Codex 5.4, और Antigravity 3.1 को अलग-अलग $20 plans पर इस्तेमाल किया।
  Codex ने 12 मिनट में इसे पूरी तरह निपटा दिया, और Antigravity से एक page छूट गया था लेकिन जल्दी ठीक हो गया। Claude Code usage limit पार होने से रुक गया, और दोबारा कोशिश के बाद भी त्रुटि रही। उम्मीद से कमज़ोर निकला

  • मैंने भी ऐसा ही प्रयोग किया, लेकिन मेरे मामले में Claude accountant-स्तर की सटीकता के साथ निकला। एक ही task पर अलग sessions में अलग नतीजे आना दिलचस्प है। non-deterministic software के दौर में customer support सच में अजीब अनुभव है

• Reddit पर आई update notice के बाद से Claude इतना बदल गया है कि रोज़मर्रा coding के लिए इस्तेमाल लायक नहीं रहा। Pro account का credit एक घंटे में खत्म हो गया, इसलिए मैं फिर से Gemini या ChatGPT पर लौट गया

• आखिरकार लगता है कि Anthropic की token billing structure आम users के खिलाफ डिज़ाइन की गई है। एक बार वास्तव में इस्तेमाल करो, तुरंत महसूस हो जाएगा कि वे कितना ज़्यादा पैसा चाहते थे