द्वारे Claude prompt caching: break-even कधी होते?
Claude मध्ये cache write साठी 1.25x आणि read साठी 0.1x आकारले जाते, त्यामुळे prefix दुसऱ्यांदा वापरल्यावर खर्च भरून निघतो. API मधून गणना तपासा.
कॅशिंगमुळे बचत होण्यापूर्वी prompt caching ची किंमत
Prompt caching मुळे Claude प्रत्येक call वेळी prompt चा सुरुवातीचा भाग पुन्हा वाचण्याऐवजी तो पुन्हा वापरू शकतो. हा निर्णय तुमच्या model च्या base input price वर लागू होणाऱ्या दोन multipliers वर अवलंबून असतो. August 2026 नुसार, 5 minute lifetime साठी cache write ची किंमत base input च्या 1.25x असते. 1 hour lifetime साठी ती 2x असते. Cache read ची किंमत 0.1x असते. हे multipliers संपूर्ण model list साठी समान आहेत. त्यामुळे per-token price बदलला तरी खालील break-even बदलत नाही.
यामध्ये आत्ताचा surcharge आणि नंतरची discount यांची तुलना होते. Prefix साठवण्यासाठी तुम्ही एकदा अतिरिक्त शुल्क देता. त्यानंतर त्याच bytes ने तंतोतंत सुरू होणाऱ्या प्रत्येक request मध्ये त्या भागासाठी normal input price च्या दहाव्या भागाइतके शुल्क आकारले जाते. Prefix त्याच्या lifetime मध्ये एकदाही पुन्हा वापरला गेला नाही, तर तुम्ही कोणतीही बचत न करता 25 percent अतिरिक्त शुल्क देता.
एका बीजगणितीय समीकरणात break-even
prefix cache न करता पाठवला असता त्याची मूळ input cost B मानू. Caching शिवाय N requests साठी B च्या N पट खर्च येतो. 5 minute cache वापरल्यास पहिली request prefix 1.25B खर्चात लिहिते आणि उर्वरित N minus 1 requests ते 0.1B खर्चात वाचतात. दोन्ही खर्च समान धरल्यास 0.9N = 1.15 मिळते, म्हणजे N = 1.28. दुसरी requestच caching न करण्यापेक्षा स्वस्त ठरते.
1 hour cache साठी 2x write धरून हीच गणना केल्यास 0.9N = 1.9 मिळते, म्हणजे N = 2.11. Long cache break-even होण्यापूर्वी दोन reads आवश्यक असतात. म्हणून तो default choice नाही.
खालील chart मध्ये Claude Opus 5 वरील 20,000 token prefix ची किंमत दाखवली आहे. August 2026 पर्यंत त्याचा base input rate प्रति million tokens $5 आहे. प्रति million tokens $3 असलेल्या model साठी प्रत्येक आकडा 0.6 ने गुणा करा. Curve चे स्वरूप बदलत नाही.
The data behind this chart
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]एकट्या request साठी caching शिवाय $0.10 आणि caching सह $0.125 खर्च येतो. त्यामुळे one-shot prompt cache करणे म्हणजे निव्वळ तोटा आहे. दुसऱ्या request पर्यंत 5 minute cache ची किंमत $0.135 असते, तर caching शिवाय किंमत $0.20 असते. त्या टप्प्यावर 1 hour cache अजूनही महाग असतो: $0.21, तर caching शिवाय किंमत $0.20 असते. तो तिसऱ्या request वरच uncached line पेक्षा कमी होतो: $0.22 विरुद्ध $0.30. 20 requests पर्यंत uncached किंमत $2.00 आणि 5 minute cache किंमत $0.315 इतकी असते.
Cache hit झाल्यावर entry चे refresh देखील होते. म्हणून प्रकाशित price table मध्ये त्या column ला cache hits and refreshes असे नाव दिले आहे. त्यामुळे व्यस्त endpoint वरील 5 minute entry read prices वर अमर्याद काळ active राहू शकते. 1 hour lifetime मधील 2x write चा खर्च तेव्हाच भरून निघतो, जेव्हा traffic मध्ये प्रत्यक्ष gaps असतात.
कमी hit rate मुळे होणारा खर्च
प्रत्यक्ष network traffic मध्ये cache miss होतात. Cache miss झालेल्या विनंतीमध्ये breakpoint असला, तरी तिचा write म्हणून शुल्क आकारले जाते. त्यामुळे hit rate च्या आधारे खर्चाचे मॉडेल तयार करणे हीच अचूक पद्धत आहे. खालील चार्टमध्ये 1,000 विनंत्यांसाठी हे दाखवले आहे. प्रत्येक विनंतीमध्ये समान 20,000 token prefix आहे.
The data behind this chart
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]0 percent hit rate वर $125.00 खर्च येतो, तर cache न वापरल्यास $100.00 खर्च आला असता. 1 hour cache मुळे हा खर्च दुप्पट होऊन $200.00 होतो. 1.25 minus 1.15h = 1 हे सोडवल्यावर 5 minute cache सुमारे 22 percent hit rate पासून खर्च वाचवू लागतो. त्यामुळे 25 percent वरच खर्च $96.25 दिसतो. 2x write साठी हीच गणना केल्यास 1 hour cache साठी सुमारे 53 percent hit rate आवश्यक ठरतो. त्यामुळे 50 percent hit rate वरही खर्च $105.00 राहतो, जो cache न वापरलेल्या रेषेपेक्षा जास्त आहे. 90 percent वर दोन्ही अनुक्रमे $21.50 आणि $29.00 वर येतात. 99 percent वर short cache $11.15 पर्यंत पोहोचतो. हा cache न वापरलेल्या किमतीच्या one tenth floor च्या जवळ आहे.
मोजमापासाठी hit rate हा मुख्य आकडा आहे, कारण prefix size निश्चित झाल्यानंतर तुमच्या नियंत्रणात राहणारा हा एकमेव input आहे.
कोणते prefix breakpoint साठी योग्य आहेत
एका request मध्ये जास्तीत जास्त चार cache breakpoints असू शकतात. त्यामुळे कोणत्या blocks ला breakpoint द्यायचा हा प्रश्न आहे. उमेदवार म्हणून अशा blocks कडे पाहा जे वेगवेगळ्या calls मध्ये byte-identical असतात आणि पुरेसे मोठे असतात. खालील chart मध्ये 5 minute cache वर 90 percent hit rate गृहीत धरून 1,000 requests साठी चार सामान्य रचनांची किंमत दाखवली आहे.
The data behind this chart
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]फक्त 2,000 token चा system prompt वापरल्यास, cache नसताना लागणाऱ्या $10.00 च्या तुलनेत 1,000 requests मागे $7.85 बचत होते. मोठ्या प्रमाणावर ही लक्षणीय बचत आहे. मात्र caching महत्त्वाचे ठरण्याचे हे मुख्य कारण नाही. Tool definitions जोडल्यावर आकार 8,000 tokens होतो आणि बचत $31.40 होते. प्रत्येक request मध्ये ज्याबद्दल प्रश्न विचारले जातात अशा 25,000 token policy document मुळे $98.12 बचत होते. शेवटची row architecture बदलते: codebase किंवा transcript context चे 120,000 tokens cache नसताना $600.00 आणि cache असताना $129.00 खर्च करतात. म्हणजे $471.00 बचत होते.
बचत prefix च्या आकारासोबत आणि hit rate सोबत वाढते. इतर कोणत्याही घटकावर ती अवलंबून नाही. त्यामुळे prompt मध्ये काय समाविष्ट करणे योग्य आहे याचा निर्णय बदलतो: एक दशलक्ष Claude tokens साठी प्रत्यक्ष किती खर्च येतो यानुसार, एकापेक्षा जास्त वेळा पाठवलेल्या कोणत्याही मजकुरासाठी दर्शविलेल्या किमतीच्या केवळ एक-दशांश खर्च येतो.
मासिक बिलावर याचा परिणाम
खालील चार्ट वरील 8,000 token prefix, system prompt आणि tool definitions यांचा 90 टक्के hit rate गृहीत धरतो आणि तो मासिक request volumes वर लागू करतो.
The data behind this chart
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]दरमहा 10,000 requests असताना बचत $314.00 इतकी आहे. ही $400.00 आणि $86.00 यांमधील फरक आहे. 100,000 requests असताना बचत $3,140.00 इतकी आहे. 1 million requests असताना uncached input bill $40,000.00 इतके असते आणि caching त्यातील $31,400.00 इतकी रक्कम वाचवते. हे आकडे फक्त input tokens साठी आहेत. Output ची किंमत स्वतंत्रपणे आकारली जाते आणि caching चा त्यावर कोणताही परिणाम होत नाही. त्यामुळे कोणालाही बिलात 90 टक्के कपात होईल असे आश्वासन देण्यापूर्वी ही बाब लक्षात ठेवा. VPS वरील AI agent चा बिलावरील खर्च नियंत्रणात ठेवण्यासाठी caching ही व्यापक पद्धतींसोबत वापरता येणारी एक स्वतंत्र पद्धत आहे.
कॅश कार्यरत असल्याचे कसे सिद्ध करावे
रचनेवर आंधळा विश्वास ठेवू नका. प्रतिसादातील usage block वाचा. प्रत्येक Messages API (application programming interface) प्रतिसादात त्याने लिहिलेले cached tokens, वाचलेले cached tokens आणि त्याला नव्याने process करावे लागलेले fresh tokens यांची माहिती दिली जाते.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)समान document आणि वेगळ्या प्रश्नासह ते दोनदा चालवा. पहिल्या call मध्ये cache_creation_input_tokens शून्यापेक्षा मोठे आणि cache_read_input_tokens शून्य असल्याचे दिसते. prefix सापडल्यामुळे दुसऱ्या call मध्ये याउलट परिणाम दिसतो. input_tokens मध्ये फक्त शेवटच्या breakpoint नंतरचे tokens मोजले जातात. त्यामुळे निरोगी दुसऱ्या call मध्ये त्याची संख्या कमी असते; सामान्यतः त्यात फक्त नवीन user message असतो. दोन्ही calls साठी शुल्क आकारले जाते, कारण Claude API मध्ये free tier नाही, तरी वर नमूद केलेल्या 20,000 token prefix साठी ही जोडी सुमारे चौदा cents इतकी पडते.
तुम्ही request.json मध्ये जतन केलेल्या request body विरुद्ध shell मधून हीच तपासणी:
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'निरोगी दुसरा call साधारणपणे असा output दाखवतो:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}एक ओळ सत्य स्पष्ट करते. calls दरम्यान cache_read_input_tokens 0 राहिला, तर प्रत्येक वेळी तुम्ही 1.25x write साठी शुल्क देत आहात आणि त्या बदल्यात काहीही परत मिळवत नाही.
1 hour lifetime साठी breakpoint मध्ये time to live (TTL) असतो:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}स्वयंचलित caching देखील उपलब्ध आहे: request च्या top level वर एकच cache_control field दिल्यानंतर API conversation वाढत असताना breakpoints स्वतः व्यवस्थापित करते. यासाठी तुमच्या चार breakpoint slots पैकी एक वापरला जातो. सुरुवात यापासून करा. boundary नेमकी कुठे असावी हे ठरवण्याची गरज असल्यास explicit breakpoints वापरा.
हिट रेट कमी करणारा क्रम नियम
कॅशे विनंतीच्या सुरुवातीपासून byte-by-byte prefix जुळवतो. विनंती ठरावीक क्रमाने तयार केली जाते: tools, त्यानंतर system, आणि शेवटी messages. कोणत्याही स्तरावर बदल झाल्यास तो स्तर आणि त्यानंतरचे सर्व स्तर invalid होतात. एका tool चे वर्णन संपादित केल्यास system prompt आणि संपूर्ण message history देखील invalid होतात, जरी त्यांच्यात थेट बदल केलेला नसला तरी.
यातून अपवाद नसलेला एक नियम मिळतो. Calls दरम्यान बदलणारी प्रत्येक गोष्ट न बदलणाऱ्या सर्व गोष्टींनंतर ठेवली पाहिजे.
यातील सामान्य कारण timestamp असते. system prompt च्या सुरुवातीला Current time: 2026-08-03T14:07:11Z असलेली ओळ 0 percent hit rate निश्चित करते, कारण प्रत्येक call वेळी prefix hash बदलतो आणि त्यापूर्वीची कोणतीही entry पुन्हा जुळू शकत नाही. ती ओळ user message मध्ये, शेवटी हलवा. Session identifier किंवा प्रत्येक request साठीचा nonce देखील याच प्रकारे अडथळा निर्माण करतो आणि त्यावर हाच उपाय लागू होतो. प्रत्येक request नुसार बदलणारी retrieved documents देखील cached block नंतर ठेवली पाहिजेत. अन्यथा बदलणाऱ्या boundary मागे असलेले सर्व स्थिर tokens देखील cache मधून बाहेर पडतात.
दुसरी समस्या बदलणाऱ्या block वर breakpoint ठेवण्याची आहे. Cache writes breakpoint वर होतात. त्यामुळे तो block प्रत्येक वेळी वेगळा असल्यास कोणतीही स्थिर माहिती साठवली जात नाही. Lookback ला फक्त आधीच्या requests ने त्यांच्या बदलत्या breakpoints वर लिहिलेल्या entries सापडतात. Requests मध्ये ज्याचा content समान असतो अशा शेवटच्या block वर cache_control ठेवा.
तिसरी समस्या prompt content म्हणून न मोजलेला parameter बदल आहे. वेगळ्या model साठी वेगळा cache असतो. Tool choice बदलल्यास system स्तरापासून पुढील सर्व भाग invalid होतात. एखादा tool जोडल्यास किंवा काढल्यास सर्वकाही invalid होते.
किमान prefix आणि शांतपणे होणारी no-op
मॉडेलच्या किमान मर्यादेपेक्षा लहान prefix cache केला जात नाही आणि याची कोणतीही सूचना मिळत नाही. Error किंवा warning दिसत नाही. Request यशस्वी होते आणि दोन्ही counters चे मूल्य 0 राहते. August 2026 पर्यंत प्रकाशित केलेल्या किमान मर्यादा पुढीलप्रमाणे आहेत:
- Claude Opus 5 आणि Claude Fable 5 वर 512 tokens
- Claude Sonnet 5 आणि Claude Opus 4.8 वर 1,024 tokens
- Claude Haiku 4.5 वर 4,096 tokens
ज्या request चा cache वापरला गेला आहे असे तुम्हाला वाटते, त्या request मध्ये दोन्ही counters चे मूल्य 0 असल्यास इतर काही तपासण्यापूर्वी prefix ची लांबी तपासा. Caching workload साठी सर्वात स्वस्त model आपोआप सर्वात कमी खर्चिक ठरत नाही, याचे हेही एक कारण आहे. Caching सुरू होण्यापूर्वी Haiku 4.5 ला Opus 5 पेक्षा आठ पट लांब prefix आवश्यक असतो. त्यामुळे 2,000 tokens चा system prompt एका model वर cache होतो, पण दुसऱ्यावर तो शांतपणे दुर्लक्षित केला जातो.
Claude Code तुमच्यासाठी कुठे cache करते आणि कुठे करू शकत नाही
Claude Code स्वतःचा prefix cache करते. System prompt आणि tool definitions प्रत्येक request च्या सुरुवातीला असतात आणि बदलत नाहीत. त्यामुळे ते एकदाच लिहिले जातात आणि session च्या उर्वरित भागासाठी पुन्हा वाचले जातात. म्हणूनच context size वरून दिसते त्यापेक्षा दीर्घ session चा प्रत्येक turn चा खर्च खूप कमी असतो. हे Claude Code token usage कसे दाखवते येथे वर्णन केलेल्या counters मध्ये दिसते.
Context च्या सुरुवातीजवळ संपादन केल्यास cache तुमची मदत करू शकत नाही. Conversation history फक्त append-only असते. त्यामुळे प्रत्येक नवीन turn आधीच cached असलेल्या prefix मध्ये पुढील मजकूर जोडतो. Session च्या सुरुवातीला वाचलेल्या file मध्ये बदल केल्यास त्या prefix च्या मध्यभागी असलेला content बदलतो. त्यामुळे त्या बदलानंतरचा प्रत्येक token पुन्हा लिहावा लागतो. बराच idle gap असतानाही हेच घडते, कारण entry expire होते आणि पुढील turn मध्ये पूर्ण write करावा लागतो. यापैकी कोणतीही गोष्ट bug नाही. Prefix rule मध्ये सांगितल्याप्रमाणे दोन्ही प्रकारेच कार्य होते.
त्याऐवजी तुम्ही स्वतःचा client लिहित असाल, तर layout नंतर बदलण्याऐवजी तो पहिल्या request पासूनच लागू करा. VPS वर पहिले Claude API app जसे करते तसे call तयार करा. स्थिर blocks आधी आणि वारंवार बदलणारे blocks शेवटी ठेवा.
अपयशाच्या स्थिती आणि त्यावेळी दिसणारे परिणाम
प्रत्येक call ही write असते. प्रत्येक request मध्ये cache_creation_input_tokens शून्येतर असते, तर cache_read_input_tokens 0 राहते. Breakpoint पर्यंतच्या किंवा त्यापूर्वीच्या एखाद्या टप्प्यावर प्रत्येक call मध्ये बदल होत आहे. सलग दोन requests मध्ये तयार केलेल्या prefix मधील पहिली 200 characters print करा आणि त्यांची प्रत्यक्ष तुलना करा.
दोन्ही counters 0 आहेत. Prefix model च्या किमान मर्यादेपेक्षा लहान आहे किंवा cache_control field API पर्यंत पोहोचलेले नाही. प्रथम prefix मधील tokens मोजा. त्यानंतर प्रत्यक्ष पाठवलेल्या request body चे logging करा.
Reads सुरू असतात आणि नंतर थांबतात. सलग काही hits मिळतात, त्यानंतर एक write होते आणि पुन्हा hits मिळतात. Requests मधील अंतर cache lifetime पेक्षा जास्त होते. तो write स्वीकारा. किंवा तुमचा hit rate 53 percent पेक्षा जास्त असल्याची खात्री झाल्यावर 1 hour TTL वापरा.
Deploy नंतर hit rate कमी होतो. Tool description संपादित केली गेली किंवा model बदलला गेला. दोन्ही बदलांमुळे संपूर्ण prefix invalidate होते. Prompt वर परिणाम करणाऱ्या प्रत्येक deploy नंतर writes ची एक महाग फेरी होईल अशी अपेक्षा ठेवा.
Caching enable केल्यानंतर bill वाढले. तुमचा hit rate break-even पेक्षा कमी आहे. 5 minute cache मध्ये सुमारे 22 percent पेक्षा कमी hit rate असल्यास prefix uncached पाठवणे स्वस्त असते. 1 hour cache मध्ये सुमारे 53 percent पेक्षा कमी hit rate असल्यासही हेच लागू होते.
FAQ
कॅशिंगचा खर्च भरून निघण्यासाठी prompt किती वेळा पुन्हा वापरावा लागतो?
5 minute cache मध्ये एकदाच पुरेसे आहे. write साठी base input च्या 1.25x इतका खर्च येतो आणि read साठी 0.1x इतका. त्यामुळे कॅशिंगशिवाय N requests चा खर्च N इतका होतो, तर caching केल्यावर N requests साठी 1.25 plus 0.1 times N minus 1 इतका खर्च होतो. हे दोन्ही N = 1.28 येथे समान होतात. त्यामुळे दुसऱ्या request पासूनच caching फायदेशीर ठरते. 1 hour cache मध्ये write साठी 2x खर्च येतो आणि दोन्ही खर्च N = 2.11 येथे समान होतात. त्यामुळे त्यासाठी दोन reads आवश्यक आहेत.
cache_read_input_tokens नेहमी zero का असते?
सर्वप्रथम prefix length तपासा: model minimum पेक्षा कमी असल्यास caching शांतपणे वगळले जाते आणि दोन्ही counters 0 दाखवतात. August 2026 पर्यंत Claude Opus 5 साठी ही मर्यादा 512 tokens आणि Claude Haiku 4.5 साठी 4,096 tokens आहे. Prefix पुरेसा मोठा असल्यास, calls दरम्यान बदलणारी content breakpoint वर किंवा त्यापूर्वी आहे का ते तपासा. उदाहरणार्थ, system prompt मधील timestamp किंवा session identifier यामुळे असे होऊ शकते. Counters पूर्वी काम करत होते आणि नंतर थांबले असल्यास, requests मधील अंतर cache lifetime पेक्षा जास्त होते.
prompt caching मुळे Claude ची उत्तरे बदलतात का?
नाही. Cache तुम्ही आधी पाठवलेल्या tokens चे processed form साठवतो. दोन्ही प्रकारे model ला तोच prompt दिसतो. हे billing आणि latency साठीचे feature आहे; behaviour बदलणारे feature नाही. त्यामुळे कार्यरत prompt वर ते enable करून evaluations पुन्हा चालवण्याची गरज नाही.
1 hour cache साठी पैसे द्यावेत का?
तुमच्या traffic मध्ये 5 minutes पेक्षा जास्त अंतर असेल आणि hit rate साधारण 53 percent पेक्षा जास्त राहणार असेल, तेव्हाच. Cache miss झाल्यावर 2x write मुळे 1.25x write च्या तुलनेत दुप्पट downside येतो. 5 minute entry प्रत्येक hit वर refresh होते. त्यामुळे steady traffic असल्यास ती read prices वर सक्रिय राहते आणि जास्त lifetime साठी अतिरिक्त खर्च करावा लागत नाही.