लेखक: Claude prompt caching: break-even point कैसे निकालें
Claude prompt caching में cache write की लागत 1.25x और read की 0.1x होती है। यह लेख गणितीय गणना के जरिए बताता है कि आपका prefix दूसरे उपयोग पर ही कैसे लाभ देने लगता है।
Prompt caching के बचत से पहले की लागत
Prompt caching आपको Claude के prompt के शुरुआती हिस्से को बार-बार पढ़ने के बजाय उसे पुनः उपयोग करने की सुविधा देता है। यह पूरा निर्णय आपके मॉडल की base input price पर लागू होने वाले दो multipliers पर निर्भर करता है। अगस्त 2026 तक, 5 मिनट की lifetime के लिए cache write की लागत base input का 1.25 गुना है, या 1 घंटे की lifetime के लिए 2 गुना है। Cache read की लागत 0.1 गुना है। ये multipliers सभी मॉडल्स पर समान रूप से लागू होते हैं, इसलिए जब प्रति-टोकन कीमत बदलती है, तो नीचे दिया गया break-even बिंदु नहीं बदलता है।
यह सौदा अभी के अतिरिक्त शुल्क और भविष्य की छूट के बीच का है। आप एक prefix को स्टोर करने के लिए एक बार अतिरिक्त भुगतान करते हैं। इसके बाद हर अनुरोध जो बिल्कुल उन्हीं bytes से शुरू होता है, उस हिस्से के लिए सामान्य input price का दसवां हिस्सा चुकाता है। यदि कोई prefix अपनी lifetime के दौरान कभी भी दोबारा उपयोग नहीं किया जाता है, तो आपको 25 प्रतिशत अतिरिक्त लागत का कोई लाभ नहीं मिलता है।
ब्रेक-ईवन, बीजगणित की एक पंक्ति में
यदि आप बिना कैशिंग के prefix भेजते हैं, तो इसकी मूल इनपुट लागत को B मानें। बिना कैशिंग के, N अनुरोधों की लागत N गुना B होती है। 5 मिनट वाले कैश के साथ, पहला अनुरोध 1.25B पर prefix लिखता है और अन्य N घटाव 1 अनुरोध इसे 0.1B पर पढ़ते हैं। दोनों को बराबर रखने पर आपको 0.9N = 1.15 प्राप्त होता है, इसलिए N = 1.28 है। दूसरा अनुरोध बिना कैशिंग के तुलना में पहले ही सस्ता हो जाता है।
इसे 1 घंटे वाले कैश के 2x राइट (write) के साथ दोहराएं और आपको 0.9N = 1.9 प्राप्त होगा, इसलिए N = 2.11 है। लंबे कैश को ब्रेक-ईवन तक पहुँचने के लिए दो रीड (read) की आवश्यकता होती है, यही कारण है कि यह डिफ़ॉल्ट विकल्प नहीं है।
नीचे दिया गया चार्ट Claude Opus 5 पर 20,000 टोकन prefix के लिए इसकी कीमत निर्धारित करता है, जिसकी मूल इनपुट दर अगस्त 2026 तक प्रति मिलियन टोकन $5 है। $3 प्रति मिलियन वाले मॉडल के लिए प्रत्येक आंकड़े को 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"
}
]एक अकेला अनुरोध बिना कैशिंग के $0.10 और कैशिंग के साथ $0.125 का पड़ता है, इसलिए वन-शॉट प्रॉम्प्ट को कैश करना पूरी तरह से नुकसान है। दूसरे अनुरोध तक, 5 मिनट वाला कैश $0.20 के मुकाबले $0.135 पर होता है। 1 घंटे वाला कैश उस बिंदु पर अभी भी पीछे है, जो उसी $0.20 के मुकाबले $0.21 है, और यह तीसरे अनुरोध पर ही बिना कैशिंग वाली लाइन से आगे निकलता है: $0.30 के मुकाबले $0.22। 20 अनुरोधों तक, अंतर $0.315 के मुकाबले $2.00 का होता है।
कैश हिट एंट्री को रिफ्रेश भी करता है, यही कारण है कि प्रकाशित मूल्य तालिका उस कॉलम को कैश हिट्स और रिफ्रेश कहती है। इसलिए एक व्यस्त एंडपॉइंट 5 मिनट वाली एंट्री को रीड कीमतों पर अनिश्चित काल तक जीवित रखता है, और 1 घंटे की लाइफटाइम केवल तभी अपना 2x राइट वसूल करती है जब आपके ट्रैफ़िक में वास्तविक अंतराल हों।
खराब हिट रेट की लागत
वास्तविक ट्रैफिक में मिस (miss) होते हैं। यदि कोई रिक्वेस्ट कैश में नहीं मिलती लेकिन उसमें ब्रेकपॉइंट मौजूद है, तो उसे राइट (write) के रूप में चार्ज किया जाता है। इसलिए, इसे मॉडल करने का सही तरीका हिट रेट के फलन (function) के रूप में लागत की गणना करना है। नीचे दिया गया चार्ट 1,000 रिक्वेस्ट के लिए ऐसा ही करता है, जिनमें से प्रत्येक में 20,000 टोकन का समान प्रीफिक्स है।
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 प्रतिशत हिट रेट पर आप $100.00 के बजाय $125.00 का भुगतान करते हैं, और 1 घंटे का कैश बिल को दोगुना करके $200.00 कर देता है। 1.25 minus 1.15h = 1 को हल करने पर पता चलता है कि 5 मिनट का कैश लगभग 22 प्रतिशत हिट रेट पर पैसे बचाना शुरू कर देता है, यही कारण है कि 25 प्रतिशत पर पहले से ही $96.25 दिखाई देता है। 2x राइट पर यही गणना करने पर 1 घंटे के कैश के लिए लगभग 53 प्रतिशत का परिणाम मिलता है, इसलिए 50 प्रतिशत हिट रेट पर भी लागत $105.00 रहती है, जो अनकैश्ड लाइन से ऊपर है। 90 प्रतिशत पर ये दोनों $21.50 और $29.00 पर पहुँच जाते हैं। 99 प्रतिशत पर छोटा कैश $11.15 तक पहुँच जाता है, जो अनकैश्ड कीमत के दसवें हिस्से के न्यूनतम स्तर के करीब है।
हिट रेट वह संख्या है जिसे आपको मॉनिटर (instrument) करना चाहिए, क्योंकि प्रीफिक्स साइज तय हो जाने के बाद यही एकमात्र इनपुट है जिसे आप नियंत्रित कर सकते हैं।
किन prefixes के लिए breakpoint बनाना सार्थक है
एक request में चार cache breakpoints तक हो सकते हैं, इसलिए प्रश्न यह है कि किन blocks को breakpoint की आवश्यकता है। इसके लिए वे blocks उपयुक्त हैं जो हर call में byte-identical रहते हैं और जिनका आकार इतना बड़ा है कि वे मायने रखते हैं। नीचे दिया गया चार्ट 5 मिनट के cache पर 90 प्रतिशत 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 प्रति 1,000 requests पर $7.85 की बचत करता है, जबकि uncached होने पर यह लागत $10.00 होती है। अधिक volume पर यह वास्तविक बचत है, लेकिन यह caching को दिलचस्प नहीं बनाता। यदि आप tool definitions जोड़ते हैं, तो आप 8,000 tokens तक पहुँच जाते हैं और $31.40 की बचत होती है। एक 25,000 token का policy document, जिसके बारे में हर request में प्रश्न पूछे जाते हैं, $98.12 की बचत करता है। अंतिम पंक्ति वह है जो architecture को बदल देती है: 120,000 tokens का codebase या transcript context uncached होने पर $600.00 का पड़ता है और cached होने पर $129.00 का, जिससे $471.00 की बचत होती है।
बचत prefix के आकार और hit rate के साथ बढ़ती है, और किसी अन्य कारक के साथ नहीं। यह इस बात को बदल देता है कि prompt में क्या डालना सार्थक है: एक मिलियन Claude tokens की वास्तविक लागत उस किसी भी चीज़ के लिए अंकित मूल्य के दसवें हिस्से तक गिर जाती है जिसे आप एक से अधिक बार भेजते हैं।
मासिक बिल पर यह कैसा दिखता है
नीचे दिया गया चार्ट ऊपर दिए गए 8,000 टोकन प्रीफिक्स, एक सिस्टम प्रॉम्प्ट और टूल डेफिनिशन को 90 प्रतिशत हिट रेट पर लेता है, और इसे मासिक अनुरोध वॉल्यूम के अनुसार स्केल करता है।
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 अनुरोधों पर बचत $314.00 है, जो $400.00 और $86.00 के बीच का अंतर है। 100,000 अनुरोधों पर यह $3,140.00 है। दस लाख अनुरोधों पर अनकैश्ड इनपुट बिल $40,000.00 है और कैशिंग इसमें से $31,400.00 की कटौती करती है। ये केवल इनपुट टोकन हैं। आउटपुट की कीमत अलग से तय की जाती है और कैशिंग का उस पर कोई प्रभाव नहीं पड़ता है, जिसे किसी को भी 90 प्रतिशत बिल कटौती का वादा करने से पहले याद रखना चाहिए। कैशिंग VPS पर AI एजेंट के बिल को नियंत्रित रखने की व्यापक आदतों के साथ काम करती है।
कैश काम कर रहा है, यह कैसे सिद्ध करें
डिज़ाइन पर भरोसा न करें। रिस्पॉन्स पर मौजूद usage ब्लॉक को पढ़ें। प्रत्येक Messages API (application programming interface) रिप्लाई उन cached टोकन की रिपोर्ट करता है जिन्हें उसने लिखा, जिन्हें उसने पढ़ा, और उन नए टोकन की जिन्हें उसे प्रोसेस करना पड़ा।
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)एक ही डॉक्यूमेंट और अलग-अलग प्रश्नों के साथ इसे दो बार चलाएं। पहली कॉल एक गैर-शून्य cache_creation_input_tokens और एक शून्य cache_read_input_tokens की रिपोर्ट करती है। दूसरी कॉल इसे उलट देती है, क्योंकि प्रीफ़िक्स मिल गया था। input_tokens केवल अंतिम ब्रेकपॉइंट के बाद के टोकन की गिनती करता है, इसलिए एक सही ढंग से काम कर रही दूसरी कॉल पर यह संख्या छोटी होती है, आमतौर पर केवल नया यूज़र मैसेज। दोनों कॉल के लिए बिलिंग होती है, क्योंकि Claude API का कोई फ्री टियर नहीं है, हालांकि ऊपर बताए गए 20,000 टोकन प्रीफ़िक्स की कीमत लगभग चौदह सेंट आती है।
शेल से वही जाँच, एक रिक्वेस्ट बॉडी के विरुद्ध जिसे आपने request.json में सेव किया है:
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'एक सही ढंग से काम कर रही दूसरी कॉल कुछ इस तरह प्रिंट करती है:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}एक लाइन आपको सच्चाई बताती है। यदि cache_read_input_tokens कॉल के दौरान 0 पर ही रहता है, तो आप हर बार 1.25x राइट (write) के लिए भुगतान कर रहे हैं और बदले में कुछ भी प्राप्त नहीं कर रहे हैं।
1 घंटे की लाइफटाइम के लिए, ब्रेकपॉइंट में एक टाइम टू लिव (TTL) होता है:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}इसमें ऑटोमैटिक कैशिंग भी है: रिक्वेस्ट के टॉप लेवल पर एक सिंगल cache_control फ़ील्ड, जिसके बाद बातचीत बढ़ने पर API ब्रेकपॉइंट्स को मैनेज करता है। यह आपके चार ब्रेकपॉइंट स्लॉट में से एक का उपयोग करता है। वहीं से शुरुआत करें। जब आपको यह तय करने की आवश्यकता हो कि बाउंड्री ठीक कहाँ स्थित है, तब स्पष्ट ब्रेकपॉइंट्स (explicit breakpoints) पर जाएँ।
हिट रेट को खत्म करने वाला ऑर्डरिंग नियम
कैश अनुरोध की शुरुआत से बाइट-दर-बाइट प्रीफिक्स का मिलान करता है, और अनुरोध को एक निश्चित क्रम में संयोजित किया जाता है: tools, फिर system, और अंत में messages। किसी भी स्तर पर किया गया बदलाव उस स्तर और उसके बाद की हर चीज़ को अमान्य (invalidate) कर देता है। यदि आप एक tool विवरण बदलते हैं, तो system prompt और पूरा message history भी उसके साथ अमान्य हो जाता है, भले ही आपने उन्हें न छुआ हो।
इसका एक ही नियम है जिसका कोई अपवाद नहीं है। जो कुछ भी कॉल के बीच बदलता है, उसे उन सभी चीज़ों के बाद आना चाहिए जो नहीं बदलती हैं।
आमतौर पर समस्या timestamp के कारण होती है। system prompt के शीर्ष पर Current time: 2026-08-03T14:07:11Z वाली एक लाइन 0 प्रतिशत हिट रेट की गारंटी देती है, क्योंकि प्रीफिक्स हैश हर कॉल पर अलग होता है और कोई भी पिछला एंट्री उससे मेल नहीं खा सकती। इसे user message के अंत में ले जाएँ। एक session identifier या प्रति-अनुरोध nonce भी इसी तरह काम बिगाड़ते हैं और उनका समाधान भी वही है। जो retrieved documents हर अनुरोध पर अलग होते हैं, उन्हें भी cached ब्लॉक के बाद ही रखा जाना चाहिए, अन्यथा वे हर स्थिर टोकन को एक ऐसे दायरे के पीछे धकेल देते हैं जो लगातार बदलता रहता है।
दूसरी समस्या breakpoint को उस ब्लॉक पर रखना है जो बदलता रहता है। कैश राइट्स (cache writes) breakpoint पर होते हैं, इसलिए यदि वह ब्लॉक हर बार अलग होता है, तो कुछ भी स्थिर स्टोर नहीं हो पाता, और lookback को केवल वही एंट्रीज़ मिलती हैं जिन्हें पिछले अनुरोधों ने अपने स्वयं के बदलते breakpoints पर लिखा था। cache_control को उस अंतिम ब्लॉक पर रखें जिसकी सामग्री सभी अनुरोधों में समान रहती है।
तीसरी समस्या एक ऐसा पैरामीटर बदलाव है जिसे आप prompt सामग्री के रूप में नहीं सोचते हैं। एक अलग model का कैश अलग होता है। tool choice बदलने से system स्तर से आगे की हर चीज़ अमान्य हो जाती है। किसी tool को जोड़ने या हटाने से सब कुछ अमान्य हो जाता है।
न्यूनतम प्रीफिक्स और साइलेंट नो-ऑप
मॉडल के न्यूनतम प्रीफिक्स से छोटा प्रीफिक्स कैश नहीं किया जाता है, और इसकी कोई सूचना नहीं मिलती है। न कोई त्रुटि, न कोई चेतावनी। अनुरोध सफल हो जाता है और दोनों काउंटर 0 दर्शाते हैं। अगस्त 2026 तक प्रकाशित न्यूनतम सीमाएँ इस प्रकार हैं:
- Claude Opus 5 और Claude Fable 5 पर 512 टोकन
- Claude Sonnet 5 और Claude Opus 4.8 पर 1,024 टोकन
- Claude Haiku 4.5 पर 4,096 टोकन
यदि किसी ऐसे अनुरोध पर दोनों काउंटर 0 दर्शाते हैं जिसके बारे में आपको लगता है कि वह कैश किया गया है, तो सबसे पहले प्रीफिक्स की लंबाई की जाँच करें। यही कारण है कि सबसे सस्ता मॉडल कैशिंग वर्कलोड के लिए हमेशा सबसे सस्ता नहीं होता है। Haiku 4.5 को कैशिंग शुरू करने के लिए Opus 5 की तुलना में आठ गुना लंबे प्रीफिक्स की आवश्यकता होती है, इसलिए 2,000 टोकन का सिस्टम प्रॉम्प्ट एक मॉडल पर कैश हो जाता है जबकि दूसरे पर चुपचाप अनदेखा कर दिया जाता है।
Claude Code आपके लिए कहाँ कैश करता है, और कहाँ नहीं कर सकता
Claude Code अपने स्वयं के prefix को कैश करता है। system prompt और tool definitions प्रत्येक request की शुरुआत में होते हैं और बदलते नहीं हैं, इसलिए उन्हें एक बार लिखा जाता है और बाकी session के लिए वहीं से पढ़ लिया जाता है। यही कारण है कि एक लंबे session की प्रति-टर्न लागत context size के अनुमान से काफी कम होती है, और यह Claude Code token usage की रिपोर्ट कैसे करता है में वर्णित काउंटरों में दिखाई देता है।
जहाँ यह आपकी मदद नहीं कर सकता, वह है context की शुरुआत के पास किया गया कोई edit। Conversation history केवल append-only होती है, इसलिए सामान्य नए टर्न उस prefix का विस्तार करते हैं जो पहले से ही कैश हो चुका है। session की शुरुआत में पढ़ी गई किसी file को edit करने से उस prefix के बीच की सामग्री बदल जाती है, और बदलाव के बाद के प्रत्येक token को फिर से लिखना पड़ता है। एक लंबा idle gap भी ऐसा ही करता है, क्योंकि entry expire हो जाती है और अगले टर्न में पूरा write cost देना पड़ता है। इनमें से कोई भी bug नहीं है। दोनों ही prefix नियम का पालन कर रहे हैं, जो बिल्कुल वैसा ही काम करता है जैसा बताया गया है।
यदि आप इसके बजाय अपना स्वयं का client लिख रहे हैं, तो उसे बाद में बदलने के बजाय पहली request से ही सही layout लागू करें: call को वैसे ही बनाएँ जैसे VPS पर पहला Claude API app करता है, जिसमें स्थिर (stable) blocks पहले और परिवर्तनशील (volatile) blocks अंत में हों।
विफलता के प्रकार और आप क्या देखेंगे
प्रत्येक कॉल एक write है। cache_creation_input_tokens हर अनुरोध पर non-zero रहता है जबकि cache_read_input_tokens 0 पर बना रहता है। ब्रेकपॉइंट पर या उससे पहले कुछ ऐसा है जो कॉल के बीच बदल जाता है। दो लगातार अनुरोधों पर अपने assembled prefix के पहले 200 characters प्रिंट करें और उनकी आंखों से तुलना करें।
दोनों counters 0 हैं। prefix मॉडल के न्यूनतम (minimum) से कम है, या cache_control फ़ील्ड कभी API तक नहीं पहुँचा। पहले prefix tokens की गिनती करें, फिर उस request body को लॉग करें जिसे आपने वास्तव में भेजा है।
Reads काम करते हैं, फिर रुक जाते हैं। hits की एक श्रृंखला, फिर एक write, फिर से hits। अनुरोधों के बीच का अंतराल lifetime से अधिक था। write को स्वीकार करें, या एक बार जब आप यह जाँच लें कि आपकी hit rate 53 प्रतिशत से अधिक है, तो 1 hour TTL पर स्विच करें।
डिप्लॉयमेंट के बाद hit rate गिर जाती है। किसी टूल के विवरण को संपादित किया गया था या मॉडल बदल दिया गया था। दोनों ही पूरे prefix को अमान्य (invalidate) कर देते हैं। हर उस डिप्लॉयमेंट के बाद एक महंगी writes की राउंड की अपेक्षा करें जो प्रॉम्प्ट को प्रभावित करता है।
कैशिंग सक्षम करने के बाद बिल बढ़ गया। आपकी hit rate break-even से नीचे है। 5 minute cache पर लगभग 22 प्रतिशत से नीचे, prefix को बिना कैश किए भेजना सस्ता है, और 53 प्रतिशत से नीचे 1 hour cache के लिए भी यही सच है।
FAQ
प्रॉम्प्ट को कितनी बार दोबारा इस्तेमाल करने पर कैशिंग का खर्च निकल आता है?
5 मिनट वाले कैश पर केवल एक बार। एक राइट (write) की लागत बेस इनपुट का 1.25 गुना होती है और एक रीड (read) की लागत 0.1 गुना, इसलिए N अनकैश्ड रिक्वेस्ट की लागत N होती है जबकि N कैश्ड रिक्वेस्ट की लागत 1.25 प्लस 0.1 गुना (N माइनस 1) होती है। ये दोनों N = 1.28 पर बराबर होते हैं, इसलिए दूसरी रिक्वेस्ट पर ही फायदा दिखने लगता है। 1 घंटे वाला कैश 2 गुना पर राइट करता है और N = 2.11 पर बराबर होता है, इसलिए इसे दो रीड की आवश्यकता होती है।
cache_read_input_tokens हमेशा शून्य क्यों रहता है?
सबसे पहले प्रीफिक्स की लंबाई जाँचें: मॉडल की न्यूनतम सीमा से नीचे, अगस्त 2026 तक Claude Opus 5 और 4 पर 512 टोकन और Claude Haiku 4.5 पर 4,096 टोकन, कैशिंग को चुपचाप छोड़ दिया जाता है और दोनों काउंटर 0 दिखाते हैं। यदि प्रीफिक्स पर्याप्त लंबा है, तो ऐसी सामग्री देखें जो कॉल के बीच बदलती है और ब्रेकपॉइंट पर या उससे पहले स्थित है, जैसे कि सिस्टम प्रॉम्प्ट में टाइमस्टैम्प या सेशन आइडेंटिफायर। यदि काउंटर काम कर रहे थे और अचानक बंद हो गए, तो रिक्वेस्ट के बीच का अंतराल कैश लाइफटाइम से अधिक था।
क्या प्रॉम्प्ट कैशिंग Claude के उत्तरों को बदलता है?
नहीं। कैश उन टोकन के प्रोसेस्ड रूप को स्टोर करता है जिन्हें आप पहले ही भेज चुके हैं, और मॉडल को दोनों स्थितियों में एक ही प्रॉम्प्ट दिखाई देता है। यह बिलिंग और लेटेंसी के लिए एक फीचर है, व्यवहार में बदलाव नहीं। इसका मतलब यह भी है कि आप अपने इवैल्यूएशन को दोबारा चलाए बिना इसे एक वर्किंग प्रॉम्प्ट पर इनेबल कर सकते हैं।
क्या मुझे 1 घंटे वाले कैश के लिए भुगतान करना चाहिए?
केवल तब जब आपके ट्रैफिक में 5 मिनट से अधिक का अंतराल हो और आपका हिट रेट फिर भी लगभग 53 प्रतिशत बना रहे। जब आप मिस करते हैं, तो 2 गुना राइट का नुकसान 1.25 गुना राइट की तुलना में दोगुना होता है। 5 मिनट वाली एंट्री हर हिट पर रिफ्रेश होती है, इसलिए स्थिर ट्रैफिक इसे रीड कीमतों पर जीवित रखता है और आपको लंबे लाइफटाइम के लिए कभी भुगतान नहीं करना पड़ता।