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

 (github.com/anthropics)
7 पॉइंट द्वारा GN⁺ 18 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • 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 इकट्ठा करने का अनुरोध कर रही है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.