Prompt caching दोहराए गए इनपुट की लागत को एक छोटे हिस्से तक घटा सकता है, लेकिन Claude, OpenAI और Gemini हर एक में इसे अलग तरह से चलाते हैं। देखें कि breakpoints, अवधि, write शुल्क और न्यूनतम आकार तीनों में कैसे अलग-अलग हैं, साथ में एक हल किया हुआ लागत उदाहरण और वे गलतियाँ जो cache hits रोक देती हैं।
हर बार जब आप लार्ज लैंग्वेज मॉडल (LLM) को request भेजते हैं, तो उसकी शुरुआत एक ही महँगी प्रक्रिया से होती है। सिस्टम प्रॉम्प्ट, टूल डेफ़िनिशन, चिपकाया गया डॉक्यूमेंटेशन और few-shot उदाहरण, सब कुछ टोकन-दर-टोकन, पूरी कीमत पर फिर से पढ़ा जाता है, जबकि पिछली call के बाद उनमें कुछ नहीं बदला होता। Prompt caching इस बर्बादी को रोकता है। प्रोवाइडर आपके दोहराए गए प्रीफ़िक्स का प्रोसेस किया हुआ रूप स्टोर कर लेता है, और जब अगली request उसे दोबारा इस्तेमाल करती है, तो सामान्य इनपुट कीमत का एक हिस्सा ही चार्ज होता है। इसे रेस्टोरेंट के mise en place की तरह समझें: कुक सर्विस से पहले शैलट एक बार काट लेता है, और उसके बाद हर ऑर्डर तैयार कंटेनरों से जोड़ा जाता है।
Claude, OpenAI और Gemini तीनों यह सुविधा देते हैं, पर लगभग हर बात में उनका तरीका अलग है: कौन तय करता है कि क्या कैश होगा, वह कितनी देर रहेगा, उसे लिखने की लागत कितनी है, और प्रॉम्प्ट कितना बड़ा होना चाहिए ताकि वह योग्य बने। यह लेख तीनों को उनके मौजूदा डॉक्यूमेंटेशन के आँकड़ों के साथ आमने-सामने रखता है, ताकि आप सही सेटअप चुन सकें और उन गलतियों से बच सकें जो चुपचाप कैशिंग बंद कर देती हैं।
जब कोई मॉडल आपका प्रॉम्प्ट पढ़ता है, तो पहला शब्द लिखने से पहले उसे हर टोकन के लिए असली काम करना पड़ता है। यह काम हर बार एक जैसा होता है जब प्रॉम्प्ट की शुरुआत एक जैसी हो। Prompt caching प्रोवाइडर को उस काम का नतीजा थोड़ी देर के लिए रखने और दोबारा इस्तेमाल करने देता है, ताकि दोहराया गया हिस्सा एक बार प्रोसेस हो और उसके बाद रियायती दर पर बिले।
कल्पना कीजिए एक कार्ड कैटलॉग की। प्रोवाइडर प्रोसेस किए गए प्रीफ़िक्स को उसके सटीक कंटेंट के फ़िंगरप्रिंट के नीचे फ़ाइल करता है। जो अगली request वही फ़िंगरप्रिंट बनाती है, वह ड्रॉअर खींच लेती है, और उसका कंटेंट शून्य से दोबारा बनाने की ज़रूरत नहीं पड़ती।
कैशिंग पहले टोकन से आगे की ओर काम करती है। कैश हुआ हिस्सा आपकी request की शुरुआत से हूबहू और बिना टूटे मेल खाना चाहिए, और पहला अंतर मैच को खत्म कर देता है। उस बिंदु के बाद का सब कुछ प्रोसेस होता है और सामान्य दर पर बिलता है।
यही एक नियम हर प्रोवाइडर की सलाह को आकार देता है। जो कंटेंट कभी नहीं बदलता उसे सबसे ऊपर रखें, और जो सब कुछ बदलता है (यूज़र का सवाल, मौजूदा तारीख, retrieve किए गए snippets) उसे नीचे धकेल दें। एक अच्छे ऊपरी हिस्से में आम तौर पर ये होते हैं:
💡 झटपट जाँच: अगर आप दो requests प्रिंट करके उनमें साझा हिस्से को हाईलाइट करें, तो हाईलाइट हुआ हिस्सा पहले अक्षर से शुरू होने वाला एक ठोस ब्लॉक होना चाहिए। बीच में कोई साझा पैराग्राफ़ इसमें नहीं गिना जाता।
प्रीफ़िक्स दोबारा इस्तेमाल होने पर तीन चीज़ें बेहतर होती हैं:
Agent loops, दस्तावेज़ पर सवाल-जवाब, लंबी चैट हिस्ट्री और बड़े rubric वाले classifiers को सबसे ज़्यादा फ़ायदा मिलता है। जो प्रॉम्प्ट हर बार अलग होता है, उसे कुछ नहीं मिलता।
तीनों में Claude आपको सबसे सीधा नियंत्रण देता है। आप तय करते हैं कि कैश होने वाला प्रीफ़िक्स कहाँ खत्म हो, और यह भी कि वह कितनी देर जिंदा रहे।
आप किसी कंटेंट ब्लॉक को ephemeral टाइप के cache_control से मार्क करते हैं, और request की शुरुआत से लेकर उस ब्लॉक तक (उसे मिलाकर) सब कुछ कैश्ड प्रीफ़िक्स बन जाता है। क्रम तय है: पहले tools, फिर system, फिर messages। आप ज़्यादा से ज़्यादा चार breakpoints लगा सकते हैं, और अगर आप पाँचवाँ ब्लॉक-लेवल breakpoint लगाने की कोशिश करें, तो API 400 एरर लौटाता है।
एक ऑटोमैटिक मोड भी है। request के टॉप लेवल पर एक cache_control फ़ील्ड जोड़ दें, और सिस्टम breakpoint को आख़िरी cacheable block पर लगा देता है, फिर बातचीत बढ़ने के साथ उसे आगे खिसकाता रहता है।
{
"model": "claude-opus-5-5",
"cache_control": { "type": "ephemeral" },
"system": "Long, stable instructions go here...",
"messages": [
{ "role": "user", "content": "Today's question" }
]
}
एक बारीकी लंबे agent sessions को फँसा देती है। जब सिस्टम कोई पिछली मैचिंग entry ढूँढता है, तो वह हर breakpoint से पीछे की ओर अधिकतम 20 positions तक ही जाँचता है। अगर एक turn में बहुत सारे blocks जुड़ते हैं, तो पिछली entry उस खिड़की से बाहर गिर सकती है, और इसका हल है प्रॉम्प्ट में पहले कहीं एक दूसरा breakpoint लगाना।
डिफ़ॉल्ट अवधि 5 मिनट है, और हर hit बिना किसी शुल्क के टाइमर रीफ़्रेश करता है। अगर आपका ट्रैफ़िक बीच-बीच में झुंडों में आता है, तो आप "ttl": "1h" के साथ एक घंटे का विकल्प चुन सकते हैं, जिसकी write कीमत ज़्यादा है।
| आइटम | मल्टीप्लायर | Opus 5.5 उदाहरण (प्रति मिलियन टोकन) |
|---|---|---|
| बेस इनपुट | 1x | $4.00 |
| 5-मिनट कैश राइट | 1.25x | $5.00 |
| 1-घंटे कैश राइट | 2x | $8.00 |
| कैश रीड | इस मॉडल पर 0.05x | $0.20 |
ज़्यादातर Claude मॉडल कैश से बेस इनपुट कीमत के 0.1x पर पढ़ते हैं। Opus 5.5 और Sonnet 5.5 टियर 0.05x पर पढ़ते हैं, और कुछ नए टियर इससे भी नीचे जाते हैं।
सीमा मॉडल पर निर्भर करती है, और यह पीढ़ियों के बीच काफ़ी बदली है:
💡 चुपचाप विफलता: न्यूनतम से छोटा प्रॉम्प्ट बिना कैशिंग के प्रोसेस होता है, और कोई error नहीं आता। इसका एकमात्र संकेत यह है कि cache field शून्य पर ही रहता है।
OpenAI की कहानी दो अध्यायों में है। लंबे समय तक कैशिंग पूरी तरह ऑटोमैटिक थी। GPT-5.6 के साथ इसमें breakpoints और एक write fee आई, जिससे यह Claude जैसी ज़्यादा लगती है।
GPT-5.5 और GPT-5.5 Pro पर सिस्टम 2,048-टोकन के अंतराल पर implicit breakpoints लगाता है, और retention prompt_cache_retention से सेट होता है, जो 24h तक सीमित है। GPT 5.4, GPT 5.1, GPT 5 और GPT 4.1 जैसे पिछले मॉडल in_memory retention सपोर्ट करते हैं, जो आम तौर पर लगभग 5 से 10 मिनट की निष्क्रियता तक चलती है, और विस्तारित 24h विकल्प भी।
कैश्ड इनपुट दर मॉडल पर निर्भर करती है, पर इन वर्ज़न पर कोई अतिरिक्त write शुल्क नहीं है। इसलिए कैशिंग आज़माने में मुफ़्त है। सबसे बुरी स्थिति में आप सामान्य कीमत देते हैं।
GPT-5.6 और उसके बाद के वर्ज़न ने नियम बदले, और नया सेटअप Claude के सेटअप के करीब है:
prompt_cache_options.mode को implicit पर सेट करने पर, breakpoint सबसे नए योग्य मैसेज के अंत में लग जाता है। explicit के साथ, आप हर breakpoint खुद prompt_cache_breakpoint से मार्क करते हैं।prompt_cache_options.ttl एक ही वैल्यू स्वीकार करता है, 30m, जो डिफ़ॉल्ट भी है।{
"model": "YOUR_GPT_5_6_MODEL",
"prompt_cache_options": { "mode": "explicit" },
"input": [
{
"role": "developer",
"content": [{
"type": "input_text",
"text": "Stable rubric and instructions...",
"prompt_cache_breakpoint": { "mode": "explicit" }
}]
},
{ "role": "user", "content": "The changing part of the request" }
]
}
प्लेटफ़ॉर्म पर तीन मौजूदा टियर हैं: GPT 5.6 Terra, GPT 5.6 Luna और GPT 5.6 Sol। बजट बनाने से पहले हर टियर की लाइव प्राइसिंग टेबल ज़रूर देखें, क्योंकि OpenAI कुछ टियर के लिए कैश्ड रीड की और सस्ती दरें बताता है।
Google दो अलग तंत्र देता है, और उनका बिलिंग तरीका अलग है। एक अपने आप होता है। दूसरा एक ऑब्जेक्ट है जिसे आप बनाते और मैनेज करते हैं।
Implicit caching सभी Gemini 2.5 और नए मॉडलों पर डिफ़ॉल्ट रूप से चालू है। आपको कोई कोड बदलना नहीं पड़ता। अगर कोई request पहले वाली request के साथ कॉमन प्रीफ़िक्स साझा करती है, तो वह hit के योग्य है, और बचत अपने आप मिल जाती है।
Gemini 2.5 Flash और 2.5 Pro के लिए न्यूनतम 2,048 टोकन हैं, और Gemini 3.5 Flash, उसके नए Flash भाई-बहनों और Gemini 3.1 Pro के लिए 4,096 टोकन। Google की अपनी सलाह प्रीफ़िक्स नियम से बिल्कुल मेल खाती है: बड़े, साझा कंटेंट को शुरुआत में रखें, और मिलते-जुलते प्रीफ़िक्स वाली requests को समय में पास-पास भेजें।
हालाँकि किसी एक request की कोई गारंटी नहीं है। Implicit caching मौके पर निर्भर करता है, और इसीलिए कुछ टीमें explicit वर्ज़न की ओर जाती हैं।
Explicit caching में आप एक cache ऑब्जेक्ट बनाते हैं, फिर requests को उसकी ओर इंगित करते हैं।
cache = client.caches.create(
model="gemini-2.5-flash",
config=types.CreateCachedContentConfig(
system_instruction="Long, stable instructions...",
contents=[big_document],
ttl="3600s",
),
)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Today's question",
config=types.GenerateContentConfig(cached_content=cache.name),
)
डिफ़ॉल्ट अवधि एक घंटा है, और आप ttl के साथ अपनी अवधि सेट कर सकते हैं, उदाहरण के लिए "300s"। बाद में आप ttl या expire_time बदल सकते हैं, और cache के बाकी किसी हिस्से को नहीं। बिलिंग के तीन हिस्से हैं: दोबारा इस्तेमाल हुए टोकन रियायती दर पर, जब तक cache मौजूद है तब तक प्रति टोकन-घंटा storage, और cache के बाहर की हर चीज़ की सामान्य कीमत। Explicit caches की न्यूनतम सीमा 2.5 मॉडलों पर 2,048 टोकन और 3.x लाइन पर 4,096 टोकन है। Interactions API सिर्फ़ implicit वाले तरीके को सपोर्ट करता है।
Google ने मॉडल पीढ़ी के अनुसार 75% से 90% तक की reuse छूट प्रकाशित की है, इसलिए अपने मॉडल के लिए यह संख्या लाइव प्राइसिंग पेज पर ज़रूर जाँचें।
| फ़ीचर | Claude | OpenAI (GPT-5.6 और बाद में) | Gemini |
|---|---|---|---|
| इसे कैसे चालू करें | cache_control breakpoints, या ऑटोमैटिक मोड के लिए एक टॉप-लेवल फ़ील्ड | डिफ़ॉल्ट रूप से implicit, या explicit breakpoints | डिफ़ॉल्ट रूप से implicit, साथ में explicit cache ऑब्जेक्ट |
| अवधि | 5 मिनट, या अनुरोध पर 1 घंटा | 30 मिनट | Implicit की गारंटी नहीं है। Explicit का डिफ़ॉल्ट 1 घंटा है |
| लिखने की लागत | 5 मिनट के लिए 1.25x, 1 घंटे के लिए 2x | 1.25x | Implicit के लिए सामान्य इनपुट कीमत। Explicit के लिए प्रति टोकन-घंटा storage |
| पढ़ने की लागत | ज़्यादातर मॉडलों पर 0.1x, Opus 5.5 और Sonnet 5.5 पर 0.05x | 0.1x | रियायती दर, हर मॉडल के हिसाब से तय |
| न्यूनतम प्रीफ़िक्स | मॉडल के अनुसार 512 से 4,096 टोकन | 1,024 दिखाई देने वाले टोकन | 2.5 पर 2,048, नए मॉडलों पर 4,096 |
| नियंत्रण | 4 breakpoints तक | Implicit या explicit मोड | आपके सेट किए TTL वाला cache ऑब्जेक्ट |
Claude के आँकड़ों से break-even बिंदु जाँचें। 1.25x पर एक 5-मिनट का write और 0.1x पर एक read मिलाकर 1.35x लागत आती है। दो बिना कैश वाली calls की लागत 2x है। तो एक दोबारा इस्तेमाल भी write की लागत वसूल कर देता है। 1-घंटे वाला विकल्प 2x पर लिखता है, इसलिए बिना कैश के जाने से बेहतर होने के लिए आपको दो reads चाहिए।
अब इसे बड़े पैमाने पर देखें। एक 20,000-टोकन का system prompt लीजिए, जो दिन में 1,000 बार भेजा जाता है, Opus 5.5 की बेस दर $4 प्रति मिलियन टोकन पर:
यूज़र मैसेज और मॉडल का आउटपुट दोनों तरह से एक जैसे बिलते हैं, इसलिए यह गणना सिर्फ़ प्रीफ़िक्स पर होने वाली बचत को अलग दिखाती है। OpenAI के पुराने मॉडलों पर, जिनमें कोई write fee नहीं है, गणित और भी सरल है। Gemini पर explicit रास्ता बिल में storage के घंटे जोड़ता है, इसलिए दिन के ज़्यादातर हिस्से में खाली पड़ा cache बचत से ज़्यादा खर्च करा सकता है।
ज़्यादातर असफल कैशिंग सेटअप प्रोवाइडर की समस्या नहीं होते। वे तीन आदतों से आते हैं।
सबसे आम बग है system prompt के ऊपर के हिस्से में "Current time: 14:32:07" जैसी लाइन। प्रीफ़िक्स हर request पर अलग होता है, इसलिए वह कभी मेल नहीं खा सकता। Anthropic भी यही जाल दस्तावेज़ करता है: एक breakpoint को ऐसे block पर लगाना जिसमें टाइमस्टैम्प और यूज़र मैसेज दोनों हों, तो cache कभी hit नहीं होता, क्योंकि किसी पहले स्थान पर कोई entry लिखी ही नहीं गई। इसका हल है breakpoint को उस आख़िरी block पर ले जाना जो requests के बीच एक जैसा रहता है, और बदलने वाली लाइन को उसके बाद रखना।
क्रम भी फ़िंगरप्रिंट का हिस्सा है। tool definitions को शफ़ल करना, retrieved documents की सूची को अलग तरीके से सॉर्ट करना, या JSON को नए field क्रम में सीरियलाइज़ करना, ये सब एक नया प्रीफ़िक्स बना देते हैं। Claude के साथ, किसी एक level पर हुआ बदलाव उस level को और उसके बाद की हर चीज़ को invalidate कर देता है: किसी tool definition को एडिट करें, तो tools, system और messages, तीनों के कैश चले जाते हैं। images जोड़ना या हटाना messages कैश को invalidate कर देता है। टूल्स की सूची को एक तय क्रम में रखें और उसे हर बार एक ही तरीके से सीरियलाइज़ करें।
5-मिनट की अवधि उस job के काम नहीं आती जो हर दस मिनट में एक request भेजती है। हर call write की कीमत चुकाती है और कभी read नहीं देखती। ऐसे में तीन विकल्प हैं: Claude पर 1-घंटे की अवधि पर जाएँ, टाइमर खत्म होने से पहले एक सस्ती keep-alive request भेजें, या काम को batch करें ताकि requests पास-पास आएँ।
💡 मोटा नियम: cache की अवधि को request के बीच के अंतराल से मिलाएँ, सेशन की लंबाई से नहीं।
किसी सेटअप पर तब तक भरोसा न करें जब तक response यह न बताए कि वह काम कर रहा है। हर प्रोवाइडर response के usage block में cache गतिविधि रिपोर्ट करता है।
| प्रोवाइडर | कहाँ देखें |
|---|---|
| Claude | usage.cache_creation_input_tokens और usage.cache_read_input_tokens |
| OpenAI | usage.input_tokens_details.cached_tokens और, GPT-5.6 और बाद के वर्ज़न पर, cache_write_tokens |
| Gemini | usage_metadata में cached token count |
Claude पर, input_tokens फ़ील्ड सिर्फ़ आख़िरी breakpoint के बाद के टोकन गिनता है, पूरा प्रॉम्प्ट नहीं। असली कुल संख्या cache_read_input_tokens + cache_creation_input_tokens + input_tokens है, इसलिए अपना hit rate उसी योग के आधार पर निकालें।
हर request के लिए तीन संख्याएँ लॉग करें: पढ़े गए कैश्ड टोकन, लिखे गए टोकन, और पूरी कीमत पर बिले टोकन। फिर दो संकेत देखें। दूसरी एक जैसी request के बाद अगर read count शून्य पर रहता है, तो इसका मतलब है कि प्रीफ़िक्स बदल रहा है या न्यूनतम से नीचे है। अगर write count हर request पर बढ़ता है, तो इसका मतलब है कि अगली call आने से पहले अवधि खत्म हो जाती है।
कैशिंग के स्विच हर प्रोवाइडर के अपने API में होते हैं, इसलिए उन्हें ट्यून करने की जगह आपका कोड है। Picasso IA एक कदम पहले काम आता है, जब आप तय कर रहे होते हैं कि स्थिर प्रीफ़िक्स में क्या लिखा हो:
फ़्रीज़ किया हुआ प्रॉम्प्ट स्थिर भी होता है, और cache को ठीक यही चाहिए।
इस लेख की सारी तस्वीरें P Image से बनाई गई हैं, हर एक लेंस, रोशनी और बनावट के बारे में एक ही वर्णनात्मक प्रॉम्प्ट से। आप कुछ मिनटों में यही कर सकते हैं। तेज़ 4K डिटेल के लिए Seedream 4.5 आज़माएँ, फ़ोटोग्राफ़िक रियलिज़्म के लिए Flux 2 Pro, प्राकृतिक दृश्यों के लिए Imagen 4, या पॉलिश्ड नतीजों के लिए Nano Banana Pro।
ऐसा प्रॉम्प्ट लिखें जो सब्जेक्ट, रोशनी और लेंस का नाम ले, उसे चलाएँ, फिर एक डिटेल बदलकर दोबारा चलाएँ। किसी मॉडल को समझने का सबसे तेज़ तरीका है आज ही Picasso IA पर अपनी इमेज के साथ प्रयोग शुरू करना।
अपनी भाषा चुनें
