लेखक: Claude prompt caching: break-even point कैसे निकालें
Claude cache write 1.25x और read 0.1x लागत पर काम करता है। जानें कि आपका prefix दूसरी बार उपयोग करने पर कैसे पैसे बचाता है और API के जरिए इसकी सटीक गणना कैसे करें।
Prompt caching की लागत और बचत का विश्लेषण
Prompt caching की मदद से Claude आपके prompt के शुरुआती हिस्से को हर बार पढ़ने के बजाय उसे पुनः उपयोग (reuse) कर सकता है। यह पूरी प्रक्रिया आपके model की base input price पर लागू होने वाले दो multipliers पर निर्भर करती है। अक्टूबर 2026 तक, हर model पर 5 मिनट की lifetime के लिए cache write की लागत base input का 1.25x है, और 1 घंटे की lifetime के लिए यह 2x है। अधिकांश models पर cache read की लागत 0.1x है, लेकिन अब यह read multiplier हर जगह समान नहीं है। Claude Fable 5.1 और Claude Mythos 5.1 पर यह 0.025x है, जिन्हें 1 सितंबर, 2026 को इसी दर पर लॉन्च किया गया था। Claude Opus 5.5 और Claude Sonnet 5.5 पर यह 0.05x है, और 7 अक्टूबर, 2026 को Sonnet 5.5 की दर को 0.1x से घटाकर यही कर दिया गया था। नीचे दिए गए गणना के आंकड़े मानक 0.1x read का उपयोग करते हैं। सस्ती reads break-even को थोड़ा आपके पक्ष में ले आती हैं, और अगला भाग यह दर्शाता है कि कितना।
यह सौदा अभी के अधिभार (surcharge) और बाद की छूट (discount) के बीच का है। आप एक prefix को store करने के लिए एक बार अतिरिक्त भुगतान करते हैं। इसके बाद हर वह request जो बिल्कुल उन्हीं bytes से शुरू होती है, उस हिस्से के लिए सामान्य input price का दसवां हिस्सा या ऊपर बताए गए models पर उससे भी कम भुगतान करती है। यदि कोई prefix अपनी lifetime के दौरान कभी दोबारा उपयोग नहीं किया जाता है, तो आपने बिना किसी लाभ के 25 प्रतिशत अतिरिक्त भुगतान किया है।
बीजगणित की एक पंक्ति में ब्रेक-ईवन (break-even)
यदि आप prefix को बिना कैश किए भेजते हैं, तो मान लें कि उसकी मूल इनपुट लागत B है। बिना कैशिंग के, N अनुरोधों की लागत N गुना B होती है। 5 मिनट वाले कैश के साथ, पहला अनुरोध prefix को 1.25B पर लिखता है और अन्य N माइनस 1 अनुरोध इसे 0.1B पर पढ़ते हैं। दोनों को बराबर रखने पर आपको 0.9N = 1.15 मिलता है, इसलिए N = 1.28। दूसरा अनुरोध ही बिना कैशिंग के तुलना में सस्ता हो जाता है।
इसे 1 घंटे वाले कैश के 2x राइट (write) के साथ दोहराएं और आपको 0.9N = 1.9 मिलता है, इसलिए N = 2.11। लंबे समय वाले कैश को ब्रेक-ईवन तक पहुँचने के लिए दो रीड (read) की आवश्यकता होती है, इसीलिए यह डिफ़ॉल्ट विकल्प नहीं है।
सस्ते रीड पर यह रेखा थोड़ी बदलती है, लेकिन बहुत अधिक नहीं। 0.05x रीड पर 5 मिनट वाला कैश 0.95N = 1.2 देता है, इसलिए N = 1.26, और 0.025x पर यह 1.225 देता है, जिससे N = 1.26 ही रहता है। 1 घंटे वाला कैश घटकर N = 2.05 और N = 2.03 पर आ जाता है। व्यावहारिक उत्तर हर मॉडल पर समान है: 5 मिनट वाला कैश दूसरे अनुरोध से ही लाभ देने लगता है, जबकि 1 घंटे वाला कैश तीसरे अनुरोध से।
नीचे दिया गया चार्ट Claude Opus 5 पर 20,000 टोकन के prefix के लिए इसकी कीमत दर्शाता है। अक्टूबर 2026 तक इसकी मूल इनपुट दर 5 डॉलर प्रति मिलियन टोकन है, जो अगस्त से अपरिवर्तित है। Opus 5 अब एक लेगेसी मॉडल है, हालांकि यह अभी भी उपलब्ध है। इसका उत्तराधिकारी, Claude Opus 5.5, 0.05x रीड के साथ 4 डॉलर प्रति मिलियन की दर पर सूचीबद्ध है, इसलिए वहां उसी prefix को लिखने की लागत 0.10 डॉलर और पढ़ने की लागत 0.004 डॉलर है। मानक 0.1x रीड वाले 3 डॉलर प्रति मिलियन मॉडल के लिए प्रत्येक आंकड़े को 0.6 से गुणा करें। वक्र (curve) का आकार नहीं बदलता है।
इस चार्ट के पीछे का डेटा
[
{
"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 का होता है।
कैश हिट (cache hit) एंट्री को रिफ्रेश भी करता है, इसीलिए प्रकाशित मूल्य तालिका उस कॉलम को 'कैश हिट्स एंड रिफ्रेशेस' (cache hits and refreshes) कहती है। इसलिए एक व्यस्त एंडपॉइंट 5 मिनट वाली एंट्री को रीड कीमतों पर अनिश्चित काल तक जीवित रखता है, और 1 घंटे वाला लाइफटाइम केवल तभी अपना 2x राइट वसूल करता है जब आपके ट्रैफिक में वास्तविक अंतराल (gaps) हों।
कम हिट रेट की लागत
वास्तविक ट्रैफिक में मिस (misses) होते हैं। एक अनुरोध जो कैश में नहीं मिलता लेकिन जिसमें ब्रेकपॉइंट होता है, उसे राइट (write) के रूप में चार्ज किया जाता है। इसलिए, लागत को हिट रेट के फलन (function) के रूप में मॉडल करना सबसे सटीक तरीका है। नीचे दिया गया चार्ट 1,000 अनुरोधों के लिए ऐसा ही करता है, जिनमें से प्रत्येक में 20,000 टोकन का समान प्रीफिक्स है।
इस चार्ट के पीछे का डेटा
[
{
"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 माइनस 1.15h = 1 को हल करने पर, 5 मिनट वाला कैश लगभग 22 प्रतिशत के हिट रेट पर पैसे बचाना शुरू कर देता है, यही कारण है कि 25 प्रतिशत पर पहले से ही $96.25 दिखाई देता है। 2x राइट पर यही गणना 1 घंटे वाले कैश के लिए लगभग 53 प्रतिशत का परिणाम देती है, इसलिए 50 प्रतिशत हिट रेट पर भी लागत $105.00 रहती है, जो अनकैश्ड लाइन से ऊपर है। 90 प्रतिशत पर दोनों $21.50 और $29.00 पर पहुँच जाते हैं। 99 प्रतिशत पर छोटा कैश $11.15 तक पहुँच जाता है, जो अनकैश्ड मूल्य के दसवें हिस्से के न्यूनतम स्तर के करीब है।
0.05x रीड वाले मॉडल पर, थ्रेशोल्ड 5 मिनट वाले कैश के लिए लगभग 21 प्रतिशत और 1 घंटे वाले कैश के लिए 51 प्रतिशत तक गिर जाते हैं। 0.025x रीड पर, वे लगभग 20 और 51 प्रतिशत तक गिर जाते हैं। रीड की कीमत के साथ न्यूनतम स्तर गिरकर अनकैश्ड लागत के बीसवें या चालीसवें हिस्से तक पहुँच जाता है।
हिट रेट वह संख्या है जिसे आपको इंस्ट्रूमेंट (instrument) करना चाहिए, क्योंकि प्रीफिक्स साइज तय होने के बाद यही एकमात्र इनपुट है जिसे आप नियंत्रित कर सकते हैं।
किन prefixes पर breakpoint लगाना सार्थक है
एक request में अधिकतम चार cache breakpoints हो सकते हैं, इसलिए प्रश्न यह है कि किन blocks पर breakpoint लगाना चाहिए। इसके लिए वे blocks उपयुक्त हैं जो हर call में byte-identical रहते हैं और जिनका आकार इतना बड़ा है कि वे मायने रखते हैं। नीचे दिया गया चार्ट 5 मिनट के cache पर 90 प्रतिशत hit rate के साथ 1,000 requests के लिए चार सामान्य आकारों की लागत दर्शाता है।
इस चार्ट के पीछे का डेटा
[
{
"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, uncached स्थिति में लगने वाले $10.00 के मुकाबले प्रति 1,000 requests पर $7.85 की बचत करता है। अधिक 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 की वास्तविक लागत उन सभी चीजों के लिए, जिन्हें आप एक से अधिक बार भेजते हैं, sticker price के दसवें हिस्से या उससे भी कम हो जाती है, विशेषकर उन models पर जिनमें read की लागत कम है।
मासिक बिल पर यह कैसा दिखता है
नीचे दिया गया चार्ट ऊपर दिए गए 8,000 टोकन प्रीफिक्स, एक सिस्टम प्रॉम्प्ट और टूल डेफिनिशन को 90 प्रतिशत हिट रेट पर लेता है, और इसे मासिक अनुरोध वॉल्यूम के अनुसार स्केल करता है।
इस चार्ट के पीछे का डेटा
[
{
"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 भी उसके साथ अमान्य हो जाते हैं, भले ही आपने उन्हें न छुआ हो।
इससे एक नियम बनता है जिसका कोई अपवाद नहीं है। जो कुछ भी कॉल के बीच बदलता है, उसे उन सभी चीजों के बाद आना चाहिए जो नहीं बदलती हैं।
आमतौर पर समस्या एक टाइमस्टैम्प के कारण होती है। system prompt के शीर्ष पर Current time: 2026-08-03T14:07:11Z वाली एक लाइन 0 प्रतिशत हिट रेट की गारंटी देती है, क्योंकि प्रीफिक्स हैश हर कॉल पर अलग होता है और कोई भी पिछला एंट्री उससे मेल नहीं खा सकती। इसे user message के अंत में ले जाएं। एक session identifier या प्रति-अनुरोध nonce भी इसी तरह काम बिगाड़ते हैं और उनका समाधान भी वही है। जो retrieved documents हर अनुरोध पर अलग होते हैं, उन्हें भी cached ब्लॉक के बाद रखा जाना चाहिए, अन्यथा वे हर स्थिर टोकन को एक ऐसी सीमा के पीछे धकेल देते हैं जो लगातार बदलती रहती है।
दूसरी समस्या ब्रेकपॉइंट को उस ब्लॉक पर रखना है जो बदलता रहता है। कैश राइट्स ब्रेकपॉइंट पर होते हैं, इसलिए यदि वह ब्लॉक हर बार अलग होता है, तो कुछ भी स्थिर स्टोर नहीं हो पाता, और लुकबैक को केवल वही एंट्रीज मिलती हैं जिन्हें पिछले अनुरोधों ने अपने स्वयं के बदलते ब्रेकपॉइंट्स पर लिखा था। cache_control को उस अंतिम ब्लॉक पर रखें जिसकी सामग्री सभी अनुरोधों में समान रहती है।
तीसरी समस्या एक पैरामीटर परिवर्तन है जिसे आप प्रॉम्प्ट सामग्री के रूप में नहीं सोचते हैं। एक अलग model का कैश अलग होता है। tool_choice को बदलने से message history अमान्य हो जाता है, हालांकि tools और system prompt कैश में बने रहते हैं। किसी tool को जोड़ने या हटाने से सब कुछ अमान्य हो जाता है।
न्यूनतम प्रीफिक्स और साइलेंट नो-ऑप
यदि प्रीफिक्स मॉडल के न्यूनतम निर्धारित आकार से छोटा है, तो उसे कैश नहीं किया जाता है और इसकी कोई सूचना भी नहीं दी जाती है। न कोई त्रुटि (error) आती है और न ही कोई चेतावनी (warning)। अनुरोध सफल हो जाता है और दोनों काउंटर 0 दर्शाते हैं। अक्टूबर 2026 तक प्रकाशित न्यूनतम सीमाएँ इस प्रकार हैं:
- Claude Opus 5 और Claude Fable 5, तथा नए Opus 5.5, Sonnet 5.5, Fable 5.1 और Haiku 5.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 आपके लिए कहाँ cache करता है, और कहाँ नहीं कर सकता
Claude Code अपने prefix को खुद cache करता है। system prompt और tool definitions हर request की शुरुआत में होते हैं और वे बदलते नहीं हैं, इसलिए उन्हें एक बार लिखा जाता है और बाकी session के लिए वहीं से पढ़ लिया जाता है। यही कारण है कि एक लंबे session की प्रति-turn लागत context size के अनुमान से काफी कम होती है, और यह Claude Code token usage की रिपोर्ट कैसे करता है में वर्णित counters में दिखाई देता है।
जहाँ यह आपकी मदद नहीं कर सकता, वह है context की शुरुआत के पास किया गया बदलाव। Conversation history केवल append-only होती है, इसलिए सामान्य नए turns उस prefix को बढ़ाते हैं जो पहले से ही cached है। session की शुरुआत में पढ़ी गई किसी file को edit करने से यह cache नहीं टूटता, क्योंकि Claude Code पहले के read को फिर से लिखने के बजाय केवल एक note जोड़ देता है कि file बदल गई है। जो चीज़ इसे तोड़ती है, वह है models को बदलना, क्योंकि हर model का अपना अलग cache होता है। एक ऐसा MCP server connect करना जिसके tools prefix में load होते हैं, वह भी इसे तोड़ देता है, और conversation को compact करना भी यही करता है। इनमें से हर क्रिया के कारण अगले turn में prefix को फिर से लिखना पड़ता है। एक लंबा idle gap भी ऐसा ही करता है, क्योंकि entry expire हो जाती है और अगले turn में पूरा write cost देना पड़ता है। इनमें से कोई भी bug नहीं है। ये prefix के नियम हैं जो बिल्कुल वैसा ही काम कर रहे हैं जैसा बताया गया है।
यदि आप इसके बजाय अपना खुद का client लिख रहे हैं, तो पहले request वाले layout को ही लागू करें, न कि उसे बाद में बदलें: call को वैसे ही बनाएँ जैसे VPS पर पहला Claude API app करता है, जिसमें stable blocks पहले और volatile blocks अंत में होते हैं।
विफलता के प्रकार, और आप क्या देखेंगे
प्रत्येक कॉल एक write है। हर अनुरोध पर cache_creation_input_tokens शून्य नहीं होता है जबकि cache_read_input_tokens 0 पर ही रहता है। ब्रेकपॉइंट पर या उससे पहले कुछ ऐसा है जो कॉल के बीच बदल जाता है। लगातार दो अनुरोधों पर अपने असेंबल किए गए प्रीफिक्स के पहले 200 वर्णों को प्रिंट करें और उनकी आंखों से तुलना करें।
दोनों काउंटर 0 हैं। प्रीफिक्स मॉडल के न्यूनतम स्तर से कम है, या cache_control फ़ील्ड कभी API तक नहीं पहुँचा। पहले प्रीफिक्स टोकन की गिनती करें, फिर उस अनुरोध बॉडी को लॉग करें जिसे आपने वास्तव में भेजा है।
रीड काम करते हैं, फिर रुक जाते हैं। हिट्स की एक श्रृंखला, फिर एक write, फिर से हिट्स। अनुरोधों के बीच का अंतराल लाइफटाइम से अधिक था। write को स्वीकार करें, या 1 घंटे के TTL पर तब जाएँ जब आपने यह जाँच लिया हो कि आपकी हिट दर 53 प्रतिशत से अधिक है, या 0.05x या 0.025x रीड वाले मॉडल पर लगभग 51 प्रतिशत है।
डिप्लॉय के बाद हिट दर गिर जाती है। किसी टूल के विवरण को संपादित किया गया था या मॉडल को बदला गया था। दोनों पूरे प्रीफिक्स को अमान्य कर देते हैं। हर उस डिप्लॉय के बाद एक महंगी write राउंड की अपेक्षा करें जो प्रॉम्प्ट को प्रभावित करता है।
कैशिंग सक्षम करने के बाद बिल बढ़ गया। आपकी हिट दर ब्रेक-ईवन से नीचे है। 5 मिनट के कैश पर लगभग 22 प्रतिशत से नीचे, प्रीफिक्स को बिना कैश किए भेजना सस्ता है, और लगभग 53 प्रतिशत से नीचे 1 घंटे के कैश के लिए भी यही सच है। सस्ते-रीड वाले मॉडलों पर ये सीमाएँ लगभग 20 से 21 प्रतिशत और 51 प्रतिशत पर होती हैं।
FAQ
किसी प्रॉम्प्ट को कितनी बार दोबारा इस्तेमाल करना चाहिए ताकि कैशिंग का खर्च निकल आए?
5 मिनट वाले कैश पर केवल एक बार। अधिकांश मॉडल्स पर राइट (write) की लागत बेस इनपुट का 1.25 गुना और रीड (read) की लागत 0.1 गुना होती है, इसलिए N अनकैश्ड (uncached) रिक्वेस्ट की लागत N होती है, जबकि N कैश्ड रिक्वेस्ट की लागत 1.25 प्लस 0.1 गुना N माइनस 1 होती है। ये दोनों N = 1.28 पर बराबर होते हैं, इसलिए दूसरी रिक्वेस्ट पर ही फायदा दिखने लगता है। 0.05 गुना या 0.025 गुना रीड वाले मॉडल्स पर यह बिंदु N = 1.26 होता है, जिसका परिणाम वही रहता है। 1 घंटे वाला कैश 2 गुना पर राइट करता है और N = 2.11 पर बराबर होता है, या सस्ते रीड पर लगभग 2.05 पर, इसलिए इसके लिए दो रीड की आवश्यकता होती है।
cache_read_input_tokens हमेशा शून्य क्यों रहता है?
सबसे पहले प्रीफिक्स की लंबाई जाँचें: मॉडल की न्यूनतम सीमा से नीचे, यानी अक्टूबर 2026 तक Claude Opus 5 पर 512 टोकन और Claude Haiku 4.5 पर 4,096 टोकन से कम होने पर, कैशिंग को चुपचाप छोड़ दिया जाता है और दोनों काउंटर 0 दिखाते हैं। यदि प्रीफिक्स पर्याप्त लंबा है, तो ऐसी सामग्री देखें जो कॉल्स के बीच बदलती है और ब्रेकपॉइंट पर या उससे पहले स्थित है, जैसे कि सिस्टम प्रॉम्प्ट में टाइमस्टैम्प या सेशन आइडेंटिफायर। यदि काउंटर पहले काम कर रहे थे और अब बंद हो गए हैं, तो रिक्वेस्ट के बीच का अंतराल कैश लाइफटाइम से अधिक हो गया है।
क्या प्रॉम्प्ट कैशिंग Claude के उत्तरों को बदलती है?
नहीं। कैश उन टोकन्स के प्रोसेस्ड रूप को स्टोर करता है जिन्हें आप पहले ही भेज चुके हैं, और मॉडल दोनों स्थितियों में एक ही प्रॉम्प्ट देखता है। यह बिलिंग और लेटेंसी (latency) के लिए एक फीचर है, न कि व्यवहार में बदलाव। इसका मतलब यह भी है कि आप अपने इवैल्यूएशन को दोबारा चलाए बिना इसे एक वर्किंग प्रॉम्प्ट पर इनेबल कर सकते हैं।
क्या मुझे 1 घंटे वाले कैश के लिए भुगतान करना चाहिए?
केवल तब जब आपके ट्रैफिक में 5 मिनट से अधिक का अंतराल हो और आपका हिट रेट फिर भी लगभग 53 प्रतिशत, या सस्ते रीड वाले मॉडल पर लगभग 51 प्रतिशत बना रहे। मिस (miss) होने पर, 2 गुना वाला राइट, 1.25 गुना वाले राइट की तुलना में चार गुना अधिक महंगा पड़ता है। 1 घंटे वाले राइट के मिस होने पर प्रीफिक्स की पूरी बेस इनपुट कीमत बर्बाद हो जाती है, जबकि 5 मिनट वाले राइट के मिस होने पर उसका केवल एक चौथाई हिस्सा ही बर्बाद होता है। 5 मिनट वाली एंट्री हर हिट पर रिफ्रेश होती है, इसलिए स्थिर ट्रैफिक इसे रीड कीमतों पर जीवित रखता है और आपको लंबी लाइफटाइम के लिए भुगतान नहीं करना पड़ता।