Anthropic ने 6 मार्च 2026 को cache TTL को 1 घंटे से घटाकर 5 मिनट किया

 (github.com/anthropics)
1 पॉइंट द्वारा GN⁺ 19 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2026 मार्च की शुरुआत में Claude Code का cache TTL 1 घंटे से बदलकर 5 मिनट कर दिया गया, और एक ही usage pattern में भी server-side configuration के अंतर के कारण यह बदलाव देखा गया
  • TTL घटने से cache regeneration cost 20~32% बढ़ गई और लंबे session में quota consumption तेज़ी से बढ़ा
  • विश्लेषण के अनुसार, model के हिसाब से लगभग 17% अतिरिक्त लागत आई, और कुछ users 5-घंटे quota limit तक पहुँचने लगे
  • Anthropic ने बताया कि 6 मार्च का बदलाव एक जानबूझकर किया गया कदम था, और request के अनुसार अलग-अलग TTL लागू करके कुल लागत घटाने का लक्ष्य था
  • community ने लागत वृद्धि, transparency की कमी, और पहले से सूचना न देने की आलोचना की और TTL setting में user choice सुनिश्चित करने की मांग की

Cache TTL बदलाव से लागत और quota समस्या की रिपोर्ट

  • विश्लेषण के अनुसार 2026 मार्च की शुरुआत में Anthropic के Claude Code cache TTL का default 1 घंटे से बदलकर 5 मिनट कर दिया गया
    • 11 जनवरी 2026 से 11 अप्रैल तक के 119,866 API call data points के आधार पर विश्लेषण किया गया
    • 6 मार्च से 8 मार्च के बीच 5-मिनट TTL फिर से दिखाई देने लगा और 1-घंटे TTL धीरे-धीरे गायब हो गया
    • यह एक ही client version और एक ही usage pattern में हुआ, इसलिए इसे server-side setting change के रूप में पहचाना गया
  • TTL बदलाव के कारण cache creation cost 20~32% बढ़ी, और subscription users की quota consumption में तेज़ उछाल देखा गया
    • 5-मिनट TTL में यदि session 5 मिनट से अधिक रुक जाए, तो cache expire हो जाता है और पूरा context फिर से upload करना पड़ता है
    • cache regeneration, read की तुलना में अधिकतम 12.5 गुना महंगी है, और लंबे coding session में इसकी लागत जमा होती जाती है
    • फरवरी में, जब 1-घंटे TTL बना हुआ था, waste rate 1.1% था, लेकिन मार्च के बाद यह 15~53% तक उछल गया

  • लागत विश्लेषण के नतीजे

    • claude-sonnet-4-6 model: कुल लागत $5,561.17 → 1-घंटे TTL के आधार पर $4,612.09 (लगभग 17.1% अतिरिक्त खर्च)
    • claude-opus-4-6 model: कुल लागत $9,268.97 → 1-घंटे TTL के आधार पर $7,687.17 (लगभग 17.1% अतिरिक्त खर्च)
    • अलग-अलग model में waste का लगभग समान अनुपात लगातार दिखाई दिया

  • quota पर प्रभाव

    • cache creation tokens quota में पूरी तरह जोड़े जाते हैं, जबकि cache read कम weight के साथ गिने जाते हैं
    • मार्च के बाद subscription users पहली बार 5-घंटे quota limit तक पहुँचने लगे

Anthropic का आधिकारिक जवाब

  • बदलाव स्वीकार किया: 6 मार्च का बदलाव जानबूझकर किया गया कदम था और यह cache optimization work का हिस्सा था
    • इसे request type के अनुसार अलग-अलग TTL लागू करने के लिए design किया गया है, और कोई single global default मौजूद नहीं है
    • यदि सभी requests पर 1-घंटे TTL लागू किया जाए, तो उल्टा लागत बढ़ सकती है
    • 5-मिनट TTL उन requests में अधिक efficient है जिनका reuse नहीं होता, और सभी requests के मिश्रण के आधार पर कुल लागत बचत होती है
  • bug fix: v2.1.90 में उस client bug को ठीक किया गया जिसमें subscription quota पूरी तरह खत्म कर चुके session, session खत्म होने तक 5-मिनट TTL पर fixed हो जाते थे
  • मांगों पर जवाब
    1. बदलाव हुआ था, और इसे 6 मार्च को जानबूझकर लागू किया गया
    2. TTL request के अनुसार dynamically चुना जाता है, कोई global default नहीं है
    3. 1-घंटे TTL को default के रूप में restore करने या setting option देने की कोई योजना नहीं है
    4. cache read token quota accounting के तरीके पर अलग issue में आगे जानकारी दी जाएगी

community की प्रतिक्रिया

  • कई users ने लागत बढ़ने और usability घटने की ओर इशारा करते हुए असंतोष जताया

    • कई लोगों का कहना था, “5-मिनट TTL असल में session को हर 5 मिनट में restart करने जैसा बना देता है, जिससे productivity घटती है”
    • यह भी कहा गया, “subscription users पहले ही शुल्क advance में दे चुके हैं, लेकिन TTL बदलाव से वास्तविक usable time कम हो गया”
    • “user cost को प्रभावित करने वाले ऐसे बदलावों की पहले से घोषणा जरूरी है” जैसी मांगें लगातार उठीं

  • कुछ users ने कहा कि यह API users के लिए positive change है, लेकिन दूसरे users ने जवाब दिया कि “API में तो पहले से 5-मिनट TTL default था”

  • transparency की कमी को लेकर आलोचना केंद्रित रही

    • “cost-related infrastructure बदलावों के लिए बाद की सफाई नहीं, पहले की सूचना चाहिए”
    • “ऐसे ‘silent changes’ भरोसे को नुकसान पहुँचाते हैं और users पर समस्या की वजह खुद ढूंढने का बोझ डालते हैं”

  • documentation record के अनुसार default cache 5-मिनट TTL है, और 1-घंटे TTL अतिरिक्त लागत वाले option के रूप में दिया जाता है

    • जनवरी 2026 के आधिकारिक documents में भी यही विवरण देखा गया

निष्कर्ष

  • 6 मार्च 2026 को Anthropic ने Claude Code की cache TTL policy को 1 घंटे से 5 मिनट में बदल दिया
  • कंपनी ने इसे cost optimization के लिए किया गया जानबूझकर समायोजन बताया, लेकिन users ने लागत वृद्धि, quota exhaustion, और transparency की कमी को समस्या बताया
  • community अब आगे TTL setting में user choice और policy बदलावों की अग्रिम सूचना की मांग कर रही है

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

1 टिप्पणियां

 
GN⁺ 19 일 전
Hacker News की राय

  • पिछले कुछ महीनों में Claude/Codex को लेकर इंजीनियरों का मूड साफ़ तौर पर बदल गया है
    खासकर चुपचाप किए गए बदलावों के बढ़ने से लोगों में यह बेचैनी बढ़ रही है कि क्या उन्होंने जिस प्रोडक्ट के लिए शुरू में पैसे दिए थे, वह अब भी वही है
    आजकल Anthropic का ज़िक्र ज़्यादातर नकारात्मक संदर्भ में ही होता दिखता है

    • हाल में Anthropic द्वारा OpenClaw users को block करना, third-party harnesses पर रोक, reasoning intensity कम करना, response length घटाना जैसी कई कार्रवाइयाँ काफ़ी ध्यान खींचने वाली थीं
      एक समय usage अचानक 21 गुना तक बढ़ गया था, और कुल मिलाकर यह cost cutting की कोशिश लगती है
      मुझे अब भी Claude पसंद है, लेकिन दोस्तों को इसकी सिफारिश करना लगातार मुश्किल होता जा रहा है
    • हमारी कंपनी में (400+ इंजीनियर) एक महीने पहले सभी IDE subscriptions (Visual Studio, JetBrains आदि) रद्द करके Claude Code पर स्विच किया गया था
      EVP ने वीकेंड पर बनाए गए दो demos दिखाकर कहा था कि सब लोग यही फॉलो करें, लेकिन सिर्फ़ एक हफ्ते में token overuse के कारण इसका उपयोग रोकने की घोषणा आ गई
      उसके बाद से हर हफ्ते model कमजोर होता महसूस हो रहा है, इसलिए सोचता हूँ कि अभी EVP कैसा महसूस कर रहे होंगे
    • कुछ महीने पहले तक Claude Code शानदार था, लेकिन अब इसमें errors और misunderstandings इतने बढ़ गए हैं कि यह लगभग इस्तेमाल लायक नहीं रहा
      Codex पर स्विच करके देखा तो वह कहीं ज़्यादा stable लगा
      मेरा अंदाज़ा है कि रिलीज़ के तुरंत बाद इसे ताकतवर रखा जाता है, फिर समय के साथ धीरे-धीरे performance घटाई जाती है ताकि अगले release को लेकर excitement बढ़े
    • subscription लेने के बाद मैंने reasoning ability में गिरावट साफ़ महसूस की
      कई settings बदलीं और scripts से system prompt भी modify किया, लेकिन फिर भी यह अक्सर logical loops में फँस जाता है
      समझ नहीं आता कि यह bug है, जानबूझकर कमजोर किया गया है, या बस मेरा भ्रम है
    • मुझे कोई बड़ा issue महसूस नहीं हुआ
      शायद इसलिए कि मैं Claude से step-by-step refactoring करवाता हूँ
      एक बार मैंने Grafana configuration के बारे में पूछा था, तो Claude ने कहा कि उसने “बस अनुमान लगाया”, और आखिरकार 35k tokens खर्च करके सिर्फ़ एक साधारण checkbox के बारे में बताया
      मेरे सहकर्मी performance drop महसूस करके Cursor पर जा रहे हैं, लेकिन मैं अभी भी Claude का conversation flow पसंद करता हूँ, इसलिए उसे इस्तेमाल कर रहा हूँ

  • आजकल Claude Code और subscription service पहले की तुलना में बहुत कम उपयोगी लगती है
    bugs, quota के तेज़ी से खत्म होने, model performance गिरने, cache invalidation issues, quantization की आशंका जैसी कई समस्याएँ जमा होती जा रही हैं
    पहले एक ही बार में prototype implement किया जा सकता था, लेकिन अब detailed spec होने पर भी यह लगभग नामुमकिन है
    ChatGPT भी इसी तरह कमजोर होता लग रहा है
    लगता है Anthropic और OpenAI, दोनों ही कोई बुनियादी समाधान नहीं हैं

    • एक दोस्त Cursor के multi-model feature से काफ़ी संतुष्ट है
      कुछ महीने पहले तक लोग कह रहे थे कि Cursor खत्म हो चुका है, लेकिन अब उल्टा उसे अच्छी तरह इस्तेमाल कर रहे हैं
    • demand explosion की वजह से लगता है कि ज़्यादातर users को बिना बताए highly quantized models दिए जा रहे हैं
    • ये AI services ज़्यादातर loss-subsidized model पर चलती हैं, इसलिए समय के साथ quality गिरना और price बढ़ना लगभग तय रास्ता है

  • session quota limits इतने सख़्त हैं कि UX एक vicious cycle में फँस जाता है
    एक घंटे का cache खत्म होते ही दोबारा शुरू करने में ज़्यादा cost लगती है, और नतीजतन अगला session भी और जल्दी खत्म हो जाता है
    मार्च के मध्य में Pro plan पर भी session एक घंटे के भीतर खत्म हो रहा था, यानी यह व्यवहारिक रूप से इस्तेमाल के लायक नहीं था

  • title की लिखावट ग़लत थी और उससे गलतफ़हमी पैदा हुई
    “M” की जगह “min” होना चाहिए था, और इससे ऐसा लगा जैसे TTL 1 घंटे से बढ़कर 5 महीने हो गया हो

    • title बदलकर समस्या के पैमाने को छिपाया गया हो, ऐसा लगना निराशाजनक है
    • मैं भी पहले “M क्या है?” सोचकर उलझ गया था

  • आजकल Claude car wash सवाल भी अक्सर ग़लत कर देता है
    वह problem-solving की कठिनाई को बढ़ा-चढ़ाकर बताता है, या “इसमें बहुत समय लगेगा” कहकर आसान रास्ता चुनने की कोशिश करता है

    • पिछले कुछ हफ्तों में ऐसा लग रहा है कि system prompt model की मेहनत को सीमित कर रहा है
      JSON logs में “यह बहुत complex है, इसे hardcode कर देते हैं” जैसे वाक्य बार-बार दिखाई देते हैं
      लगता है Anthropic computing resources की कमी और नए users की तेज़ बढ़ोतरी के बीच संतुलन बनाने की कोशिश कर रहा है
    • मैंने ऐसा भी सुना कि Claude पहले किसी काम को “इसमें कई हफ्ते लगेंगे” कहकर मना कर रहा था, लेकिन मनाने पर वही काम 30 सेकंड में पूरा कर दिया
    • यह “loss-leading sales → panic → product destruction” का एक क्लासिक चरण लगता है
    • token consumption की रफ़्तार भी बढ़ गई है; पहले मैं 3~5 projects साथ-साथ चला लेता था, अब एक भी पूरा करना मुश्किल है
    • “risk की चिंता मत करो, बस कर दो!” जैसे strong prompts इस्तेमाल करने पर model फिर से ज़्यादा सक्रिय होकर काम करता है
      यह थोड़ा आक्रामक, लेकिन असरदार LLM motivation technique है

  • Anthropic ने GitHub issue में आधिकारिक जवाब दिया

    • thread पढ़ते समय ऐसा लगा जैसे Claude दूसरे Claude से बात कर रहा हो
    • 6 मार्च के बदलाव को स्वीकार करना दिलचस्प था। prompt analysis से इसे पकड़ने वालों को सलाम
    • कंपनी की व्याख्या तर्कसंगत थी, लेकिन “cache read likelihood” जैसे शब्द दिखावे वाले लगे, इसलिए शायद community उसे ठीक से स्वीकार नहीं कर पाई

  • मैंने खुद एक API-based chat tool बनाया और उसमें cache जोड़ा
    5 मिनट का cache बातचीत की रफ़्तार से मेल नहीं खाता, इसलिए वह अक्सर expire हो जाता है, लेकिन common prefix वाले tools में इसकी बचत काफ़ी होती है
    cache का सही उपयोग करने पर cost savings काफ़ी बड़ी हो सकती हैं

  • cache expiration policy 5 घंटे के session से मेल नहीं खाती, इसलिए मैं session usage 97% के आसपास पहुँचने पर हर 4 मिनट 50 सेकंड में minimum tokens खर्च करने वाली script से cache को जीवित रखने के बारे में सोच रहा हूँ

  • Dwarkesh podcast में सुना कि Anthropic computing resources बढ़ाने में सतर्क है
    demand में तेज़ उछाल आने पर compute कम करने की कोशिशें लगभग अपरिहार्य हो जाती हैं
    ज़्यादा पैसा लगा देने से भी यह short term में हल होने वाली समस्या नहीं है

    • ऐसा phenomenon आमतौर पर नए model की pretraining phase में अक्सर दिखता है। 3.x के समय भी ऐसा था

  • Anthropic/Claude में हो रहे अजीब बदलावों से अलग, इस पोस्ट की table data देखकर भ्रम होता है क्योंकि फरवरी और अप्रैल के cost और call counts लगभग समान दिखते हैं
    समझ नहीं आता कि मैं क्या मिस कर रहा हूँ