Anthropic प्रॉम्प्ट कैशिंग चालू करना आसान है और गलत समझना भी। पहली रिक्वेस्ट ज़्यादा महँगी पड़ सकती है, बाद की कोई रिक्वेस्ट बिना एरर के मिस हो सकती है, और एक "cached" प्रीफ़िक्स क्वालिफ़ाई करने के लिए बहुत छोटा हो सकता है।
संक्षिप्त जवाब: कैश ब्रेकपॉइंट उस कंटेंट के अंत में रखें जो रिक्वेस्ट्स के बीच बिल्कुल वैसा ही रहता है, फिर पुष्टि करें कि बाद का रिस्पॉन्स Anthropic के रिस्पॉन्स usage फ़ील्ड्स के मुताबिक cache_read_input_tokens को शून्य से ऊपर रिपोर्ट करता है। पहले कैश राइट और हर रीड की क़ीमत अपनी अनुमानित रीयूज़ संख्या के हिसाब से लगाएँ: Claude Sonnet 5.5 पर, पाँच-मिनट की विंडो के अंदर एक रीड राइट प्रीमियम की भरपाई कर देता है; एक-घंटे वाली कैश के लिए दो रीड चाहिए। ये API आँकड़े यह नहीं बताते कि Claude सब्सक्रिप्शन की लिमिट्स कैसे मीटर होती हैं।
नीचे दी गई क़ीमतें और प्रोडक्ट डिटेल्स 4 अक्टूबर 2026 को चेक की गई थीं।
Anthropic प्रॉम्प्ट कैशिंग कैसे काम करती है, और इसे कैसे चालू करें?
Claude प्रॉम्प्ट कैशिंग एक मैचिंग प्रॉम्प्ट प्रीफ़िक्स को रीयूज़ करती है ताकि मॉडल कैश्ड इनपुट पढ़ सके, बजाय उसे फिर से नए इनपुट की तरह प्रोसेस करने के। पहले API टेस्ट के लिए, ऑटोमैटिक कैशिंग इस्तेमाल करें: Messages रिक्वेस्ट में टॉप-लेवल cache_control फ़ील्ड जोड़ें। किसी मौजूदा Anthropic Messages API Python कॉल में, यह रिक्वेस्ट आर्ग्युमेंट जोड़ें (इसे client.messages.create(...) में डालें):
cache_control={"type": "ephemeral"}
यह टॉप-लेवल Anthropic कैश कंट्रोल सेटिंग प्रॉम्प्ट कैशिंग डॉक्युमेंटेशन से आती है। मौजूदा उदाहरण client.messages.create(...) इस्तेमाल करते हैं; पुराना client.beta.prompt_caching.messages.create(...) रूट अब ज़रूरी नहीं। किसी स्थिर डॉक्युमेंट या टूल सेट के लिए, एक एक्सप्लिसिट ब्लॉक-लेवल ब्रेकपॉइंट आपको कंट्रोल करने देता है कि रीयूज़ेबल प्रीफ़िक्स ठीक कहाँ ख़त्म होता है। Anthropic चार ब्रेकपॉइंट्स तक की अनुमति देता है।
हिट वेरिफ़ाई करने के लिए, एक ही मॉडल और बिना बदले प्रीफ़िक्स के साथ दो रिक्वेस्ट्स करें, और दूसरी रिक्वेस्ट कैश एक्सपायर होने से पहले शुरू हो। रिस्पॉन्स का usage ऑब्जेक्ट पढ़ें:
| फ़ील्ड | यह आपको क्या बताता है |
|---|---|
cache_creation_input_tokens |
इनपुट टोकन जो इस रिस्पॉन्स पर कैश में लिखे गए |
cache_read_input_tokens |
कैश से सर्व किए गए इनपुट टोकन |
input_tokens |
आख़िरी ब्रेकपॉइंट के बाद का अनकैश्ड इनपुट |
पहली रिक्वेस्ट में कैश क्रिएशन दिखना चाहिए। बाद की रिक्वेस्ट में कैश रीड्स दिखनी चाहिए; ऑटोमैटिक कैशिंग के साथ, एक नई टेल भी लिखी जा सकती है। Anthropic कुल इनपुट को इन तीनों फ़ील्ड्स के योग के रूप में परिभाषित करता है, इसलिए कुल प्रॉम्प्ट साइज़ के लिए अकेले input_tokens का इस्तेमाल न करें। अगर दोनों कैश काउंट शून्य हैं, तो प्रॉम्प्ट कैश नहीं हुआ। एक API usage रिस्पॉन्स उस रिक्वेस्ट-लेवल व्यवहार को साबित करता है जो आपने देखा; यह आपके पूरे प्रोडक्शन वर्कलोड की हिट रेट स्थापित नहीं करता।
पाँच-मिनट वाली कैश इस्तेमाल करें या एक-घंटे वाली?
पाँच-मिनट वाली कैश तब इस्तेमाल करें जब कॉल्स पाँच मिनट के अंदर एक ही प्रीफ़िक्स रीयूज़ करती हों। एक-घंटे वाला विकल्प तब चुनें जब असल गैप नियमित रूप से उस विंडो से आगे निकलते हों और फिर भी एक घंटे के अंदर रहते हों। Anthropic TTL की घड़ी रिक्वेस्ट शुरू होने पर चालू करता है, उसके रिस्पॉन्स ख़त्म होने पर नहीं; एक चार-मिनट का स्ट्रीम अगली रिक्वेस्ट के आने के लिए लगभग एक मिनट छोड़ता है।
ब्रेक-ईवन पॉइंट सफल रीड्स की संख्या पर निर्भर करता है, इस पर नहीं कि प्रॉम्प्ट में बस एक ब्रेकपॉइंट है या नहीं। एक सरल तुलना के लिए, Claude Sonnet 5.5 पर 100,000-टोकन का एक फ़िक्स्ड प्रीफ़िक्स लें। मौजूदा Anthropic प्राइसिंग टेबल में $2 प्रति मिलियन सामान्य इनपुट टोकन, $2.50 प्रति मिलियन पाँच-मिनट कैश राइट्स, $4 प्रति मिलियन एक-घंटे वाली राइट्स, और $0.20 प्रति मिलियन रीड्स हैं। इस मॉडल के लिए रीड बेस इनपुट का 0.1× है।
R कैश रीड्स के लिए, कैश्ड प्रीफ़िक्स की लागत write rate + (R × read rate) होती है। कैशिंग के बिना, यह base rate × (1 + R) होती है। इससे सिर्फ़ प्रीफ़िक्स के लिए ये कुल आँकड़े मिलते हैं; आउटपुट और बदलती रिक्वेस्ट टेल शामिल नहीं हैं:
| पहले राइट के बाद की रीड्स, TTL के अंदर | कैश नहीं | 5-मिनट कैश | 1-घंटा कैश |
|---|---|---|---|
| 0 | $0.20 | $0.25 (125%) | $0.40 (200%) |
| 1 | $0.40 | $0.27 (67.5%) | $0.42 (105%) |
| 2 | $0.60 | $0.29 (48.3%) | $0.44 (73.3%) |
| 4 | $1.00 | $0.33 (33%) | $0.48 (48%) |
| 10 | $2.20 | $0.45 (20.5%) | $0.60 (27.3%) |
प्रतिशत, कैश्ड लागत को बिना-कैश लागत से भाग देने पर मिलते हैं। इस मॉडल पर और इन मान्यताओं के तहत, पाँच-मिनट कैशिंग एक रीड के बाद सस्ती पड़ती है; एक-घंटे वाली कैशिंग दो के बाद सस्ती होने लगती है। पहली एक-घंटे वाली राइट की लागत सामान्य इनपुट रेट से दोगुनी होती है, इसलिए TTL बढ़ाना अपने आप में बचत नहीं है। Anthropic के मौजूदा कैश-रीड मल्टीप्लायर कुछ मॉडल्स के लिए अलग हैं—Opus 5.5 के लिए 5% और Fable 5.1 व Mythos 5.1 के लिए 2.5%—इसलिए उस मॉडल की पंक्ति से दोबारा गणना करें जिसे आप असल में कॉल करते हैं। प्राइसिंग अक्टूबर 2026 में चेक की गई।
Roy Derks का एक LinkedIn पोस्ट एक काल्पनिक उदाहरण के ज़रिए समझाता है कि "कैशिंग ने मेरा बिल बढ़ा दिया" वाली शिकायतें क्यों आती हैं: एक एजेंट हर 10 मिनट में 100,000-टोकन के रीयूज़ेबल प्रॉम्प्ट के साथ चलता है, इसलिए उसकी दस में से हर कॉल पाँच-मिनट वाली एंट्री के एक्सपायर होने के बाद आती है। हर कॉल 1.25× राइट चुकाती है और कोई भी 0.1× रीड नहीं कमाती, इसलिए $10 का अनकैश्ड इनपुट $12.50 बन जाता है, यानी 25% ज़्यादा। यह एक वर्क-आउट किया गया परिदृश्य है, कोई मापा गया वर्कलोड नहीं। इससे कोई पूर्वानुमान लगाने से पहले अपने usage काउंटर्स और कॉल इंटरवल की तुलना करें।
मेरी कैश हिट क्यों नहीं हो रही?
कैश हिट के लिए मार्क किए गए ब्रेकपॉइंट तक एक ही प्रीफ़िक्स और पात्र प्रॉम्प्ट लंबाई चाहिए।
| आपको क्या दिखता है | संभावित कारण | फ़िक्स |
|---|---|---|
| दोनों कैश काउंटर शून्य पर रहते हैं | मार्क किया गया प्रीफ़िक्स मॉडल की न्यूनतम सीमा से छोटा है। Claude Sonnet 5.5 के लिए, मौजूदा न्यूनतम सीमा 512 टोकन है; इससे छोटी रिक्वेस्ट्स बिना किसी कैश एरर के चलती हैं। | मॉडल की न्यूनतम सीमा पार करने लायक स्थिर कंटेंट शामिल करें, फिर अगले रिस्पॉन्स का usage देखें। |
| एक छोटे से रिक्वेस्ट बदलाव के बाद पूरा या बड़ा रीराइट होता है | बदले गए बाइट्स ब्रेकपॉइंट से पहले हैं। Anthropic की इनवैलिडेशन टेबल टूल डेफ़िनिशन्स, वेब सर्च, citations और speed टॉगल्स, tool_choice, इमेजेस, और thinking सेटिंग्स में बदलावों को कवर करती है; टूल-डेफ़िनिशन बदलाव पूरी कैश को इनवैलिडेट कर देते हैं। |
स्थिर निर्देश और टूल डेफ़िनिशन्स को पहले रखें; टाइमस्टैम्प, प्रति-रिक्वेस्ट वैल्यू, और नया यूज़र इनपुट स्टैटिक-प्रीफ़िक्स ब्रेकपॉइंट के बाद ले जाएँ। |
| एक बदलता हुआ आख़िरी ब्लॉक हर कॉल पर दोबारा लिखा जाता है | ऑटोमैटिक कैशिंग ब्रेकपॉइंट को आख़िरी कैशेबल ब्लॉक पर ले जाती है; अगर वह ब्लॉक बदलता है, तो पहले वाली स्थिर सीमा पर कोई रीयूज़ेबल एंट्री नहीं रहती। | आख़िरी ब्लॉक पर एक्सप्लिसिट ब्रेकपॉइंट रखें जो वैसा ही रहता है। |
| एक गैप अनपेक्षित रूप से राइट करा देता है | कैश लाइफ़टाइम एक्सपायर हो गई, या एक लंबे रिस्पॉन्स ने अगली रिक्वेस्ट शुरू होने से पहले TTL का ज़्यादातर हिस्सा इस्तेमाल कर लिया। | रिक्वेस्ट-स्टार्ट इंटरवल मापें; अगर आपकी अपेक्षित रीयूज़ विंडो को इसकी ज़रूरत है और अतिरिक्त राइट चार्ज फ़ायदेमंद साबित होता है, तो ttl: "1h" इस्तेमाल करें। |
| टूल या मैसेज एक जैसे दिखते हैं पर रीड्स गिर जाती हैं | ऑर्डरिंग या सीरियलाइज़ेशन ने प्रीफ़िक्स बदल दिया। Anthropic की ट्रबलशूटिंग गाइड चेताती है कि tool_use ब्लॉक्स के अंदर अस्थिर JSON की ऑर्डरिंग रीयूज़ तोड़ सकती है। |
टूल और मैसेज की ऑर्डरिंग स्थिर रखें और स्ट्रक्चर्ड वैल्यू को डिटरमिनिस्टिक तरीक़े से सीरियलाइज़ करें। |
रिक्वेस्ट प्रीफ़िक्स का क्रम tools, फिर system, फिर messages होता है। इस क्रम में शुरू में हुआ बदलाव बाद के कैश्ड कंटेंट को इनवैलिडेट कर देता है। ब्रेकपॉइंट एक सीमा है जहाँ Anthropic एंट्री लिखता है; यह पीछे की ओर सर्च करके किसी पहले वाले स्थिर ब्लॉक के लिए गायब कैश एंट्री नहीं बनाता। इसका लुकबैक सिर्फ़ वही एंट्रियाँ ढूँढ सकता है जो पिछली रिक्वेस्ट्स पहले लिख चुकी हों। जब usage फ़ील्ड्स ऐसी मिस दिखाएँ जिसकी वजह आप समझ न पाएँ, तो Anthropic की इनवैलिडेशन और ब्रेकपॉइंट गाइड देखें।
Claude Code प्रॉम्प्ट कैशिंग कैसे काम करती है?
Claude Code प्रॉम्प्ट कैशिंग को अपने आप मैनेज करता है। एक सामान्य Claude Code सत्र में आपको cache_control नहीं जोड़ना पड़ता। इसकी रिक्वेस्ट लेयर्स सिस्टम प्रॉम्प्ट और प्रोजेक्ट कॉन्टेक्स्ट को बढ़ती हुई बातचीत से पहले रखती हैं, इसलिए किसी पहले वाली लेयर को बदलना उसके बाद की हर चीज़ को इनवैलिडेट कर सकता है।
TTL ऑथेंटिकेशन पर निर्भर करता है: मौजूदा Claude Code प्रॉम्प्ट कैशिंग गाइड में सब्सक्रिप्शन की मुख्य बातचीत के लिए एक घंटा है, पर API कीज़ और क्लाउड प्रोवाइडर्स के लिए डिफ़ॉल्ट रूप से पाँच मिनट। Claude Code v2.1.242 या बाद का वर्ज़न प्रति-बकेट TTL सेटिंग्स सपोर्ट करता है। डॉक्युमेंट किए गए एनवायरनमेंट वेरिएबल से दोनों बकेट्स के लिए एक घंटा माँगने हेतु ENABLE_PROMPT_CACHING_1H=1 सेट करें; अलग-अलग सेटिंग्स या एनवायरनमेंट वेरिएबल्स को प्राथमिकता मिल सकती है, इसलिए यह मानने से पहले कि कौन-सा TTL लागू हुआ, गाइड की प्राथमिकता सूची देखें।
सत्र का सारांश देखने के लिए /usage चलाएँ। Claude Code का Session ब्लॉक पहले रिस्पॉन्स के बाद मुख्य बातचीत की कैश हिट रेशियो और मिस काउंट रिपोर्ट करता है। रिक्वेस्ट-लेवल सबूत के लिए, गाइड cache_creation_input_tokens और cache_read_input_tokens डॉक्युमेंट करती है; v2.1.251 या बाद के वर्ज़न पर, इसका स्टेटस-लाइन डेटा prompt_cache ऑब्जेक्ट उजागर करता है। ये काउंटर सिर्फ़ लंबे पॉज़ से मिस का अनुमान लगाने से ज़्यादा काम के हैं।
Claude Code का Prompt cache (main) डिस्प्ले संभावित कारण भी शामिल कर सकता है, पर एक सत्र का ट्रांसक्रिप्ट सार्वभौमिक निदान नहीं है। मिसाल के लिए, एक Anthropic Claude Code इशू v2.1.273 पर दो मापे गए बैकग्राउंड-सबएजेंट रिज़्यूम रिपोर्ट करता है, दोनों का निदान messages_changed के रूप में हुआ, और कैश राइट्स 243,214 व 398,622 टोकन की थीं। इसे एक वर्ज़न- और परिदृश्य-विशिष्ट रिपोर्ट की तरह लें; बिल में बदलाव को किसी सामान्य प्रोडक्ट डिफ़ेक्ट से जोड़ने से पहले अपना usage डेटा और मौजूदा रिलीज़ नोट्स देखें।
Amazon Bedrock और OpenRouter पर प्रॉम्प्ट कैशिंग में क्या बदलता है?
Bedrock प्रॉम्प्ट कैशिंग और OpenRouter प्रॉम्प्ट कैशिंग एक ही सिद्धांत पर चलती हैं—एक पात्र स्थिर प्रीफ़िक्स रीयूज़ करना—पर API सतह और रूटिंग व्यवहार प्रोवाइडर के हिसाब से बदलते हैं।
| रूट | क्या अलग है | व्यावहारिक चेक |
|---|---|---|
| Anthropic API | टॉप-लेवल ऑटोमैटिक cache_control जोड़ें, या एक्सप्लिसिट ब्लॉक-लेवल ब्रेकपॉइंट्स रखें। मौजूदा डॉक्स चार ब्रेकपॉइंट्स तक और मॉडल-विशिष्ट न्यूनतम टोकन लंबाइयाँ बताते हैं। |
Anthropic के usage.cache_creation_input_tokens और usage.cache_read_input_tokens पढ़ें। |
| Amazon Bedrock | AWS इम्प्लिसिट और एक्सप्लिसिट दोनों तरह की प्रॉम्प्ट कैशिंग डॉक्युमेंट करता है। सपोर्ट, टोकन न्यूनतम सीमा, TTL, और API फ़ील्ड्स मॉडल के हिसाब से बदलते हैं। Claude की एक्सप्लिसिट कैशिंग के लिए, AWS स्टैटिक कंटेंट के अंत में एक सरलीकृत सिंगल चेकपॉइंट देता है और लगभग 20 कंटेंट ब्लॉक्स तक पीछे चेक करता है; सटीक चेकपॉइंट और रिक्वेस्ट सिंटैक्स इस पर निर्भर करते हैं कि InvokeModel है या Converse। |
उस मॉडल और रीजन के लिए Bedrock मॉडल कार्ड देखें, फिर प्रोवाइडर रिस्पॉन्स के usage फ़ील्ड्स जाँचें। Anthropic API पेलोड को आँख बंद करके कॉपी न करें। |
| OpenRouter | OpenRouter की गाइड टॉप-लेवल ऑटोमैटिक कैशिंग और एक्सप्लिसिट प्रति-ब्लॉक मार्कर डॉक्युमेंट करती है। यह एक कैश्ड रिक्वेस्ट के बाद प्रोवाइडर स्टिकी रूटिंग इस्तेमाल कर सकती है ताकि बाद की कॉल्स उसी एंडपॉइंट पर जाएँ; मैनुअल प्रोवाइडर ऑर्डरिंग को प्राथमिकता मिलती है। इसका Responses API ऑटोमैटिक कैशिंग उजागर करता है, जबकि Anthropic-स्टाइल प्रति-ब्लॉक कंट्रोल वहाँ उजागर नहीं होते। | एक स्थिर सत्र या शुरुआती मैसेज बनाए रखें और चेक करें कि हर रिक्वेस्ट किस प्रोवाइडर ने सर्व की; रूट बदलने से रीयूज़ प्रभावित हो सकता है। |
Bedrock पर, Anthropic की मौजूदा प्लेटफ़ॉर्म गाइड कहती है कि Opus 4.6 और उससे पहले वाले मॉडल्स के लिए लीगेसी Bedrock इंटीग्रेशन टॉप-लेवल ऑटोमैटिक फ़ील्ड को रिजेक्ट करते हैं; वहाँ डॉक्युमेंटेड रास्ता एक्सप्लिसिट ब्रेकपॉइंट्स ही हैं। AWS का मौजूदा पेज मॉडल-विशिष्ट सपोर्ट, न्यूनतम सीमाएँ, और TTL बताता है। अपने सटीक मॉडल के लिए उस पेज को फ़ॉलो करें, बजाय उस पुराने इंटीग्रेशन नियम को हर Bedrock Claude मॉडल पर लागू करने के।
अगर आप एक प्रोवाइडर लेयर बना रहे हैं, तो नए इनपुट, कैश रीड्स, और कैश राइट्स को अलग-अलग usage वैल्यू के रूप में रखें। हम Muvon में Octolib बनाते हैं; इसका Anthropic अडैप्टर API के cache_read_input_tokens और एफ़ेमरल राइट फ़ील्ड्स को अलग-अलग मैप करता है, ताकि गेटवे-लेवल का कुल योग इस अंतर को न छिपाए। LLM टोकन usage और एक यूनिफ़ाइड प्रोवाइडर लेयर पर हमारे नोट्स इस बड़ी अकाउंटिंग समस्या को समझाते हैं। प्रॉक्सी-लेवल विज़िबिलिटी के लिए, OctoHub LLM प्रॉक्सी देखें; मॉडल-रूटिंग लागत के ट्रेडऑफ़ के लिए, हमारी LLM रूटिंग गाइड देखें।
अब आप कैशिंग चालू कर सकते हैं, दो रिक्वेस्ट्स कर सकते हैं, रीड फ़ील्ड वेरिफ़ाई कर सकते हैं, और मापी गई रीयूज़ कैडेंस की तुलना तारीख़ वाली प्राइसिंग टेबल से कर सकते हैं। अगर ये चारों चेक आपस में मेल नहीं खाते, तो अनुमानित बिल ऑप्टिमाइज़ करना छोड़ें और पहले प्रीफ़िक्स व प्रोवाइडर रूट की जाँच करें।
— Don
हम Muvon में Octolib बनाते हैं और कैश रीड्स व राइट्स को अलग-अलग usage फ़ील्ड्स के रूप में दिखने योग्य रखते हैं। अगर आपको कोई ऐसा प्रोवाइडर रिस्पॉन्स मिले जिससे इन आँकड़ों का मिलान करना मुश्किल हो, तो एक इशू खोलें.
