लेखक: Matt Connor
Claude prompt caching में break-even गणना कैसे करें
Cache write की लागत 1.25x और read की 0.1x है, इसलिए Claude prefix दूसरे उपयोग पर लागत वसूल करता है। API से अपना break-even सत्यापित करें।
Prompt caching से बचत होने से पहले उसकी लागत
Prompt caching आपके prompt के शुरुआती हिस्से को हर call पर फिर से पढ़ने के बजाय Claude को उसका पुनः उपयोग करने देता है। पूरा निर्णय आपके 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 पाने का trade-off है। Prefix store करने के लिए आप एक बार अतिरिक्त भुगतान करते हैं। इसके बाद उस lifetime के दौरान बिल्कुल उन्हीं bytes से शुरू होने वाली हर request में उस हिस्से के लिए सामान्य input price का दसवाँ भाग ही देना पड़ता है। जिस prefix का उसके lifetime के भीतर कभी पुनः उपयोग नहीं होता, उस पर बिना लाभ के 25 percent अतिरिक्त लागत आती है।
एक algebraic line में break-even
यदि prefix को cache के बिना भेजा जाए, तो उसकी base input cost को B मानें। Caching के बिना N requests की लागत N गुना B होगी। 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। लंबे cache को break-even तक पहुँचने के लिए दो reads चाहिए। इसी कारण यह default choice नहीं है।
नीचे दिया गया chart Claude Opus 5 पर 20,000 token prefix की कीमत दिखाता है। August 2026 तक इसकी base input rate $5 per million tokens है। $3 per million वाले model के लिए हर figure को 0.6 से scale करें। Curve का shape नहीं बदलेगा।
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 तक यह अंतर $2.00 बनाम $0.315 है।
Cache hit entry को refresh भी करता है। इसी कारण published price table में उस column का नाम cache hits and refreshes है। इसलिए busy endpoint 5 minute entry को read prices पर अनिश्चित समय तक alive रख सकता है। 1 hour lifetime का 2x write तभी उपयोगी होता है, जब आपके traffic में वास्तविक gaps हों।
कम hit rate की लागत
वास्तविक traffic में cache miss होते हैं। कोई request cache से miss हो जाए, लेकिन उसमें breakpoint अभी भी मौजूद हो, तो उसे write के रूप में charge किया जाता है। इसलिए इसकी लागत को hit rate के फ़ंक्शन के रूप में model करना सही तरीका है। नीचे दिया गया chart 1,000 requests के लिए यही दिखाता है। प्रत्येक request में समान 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 bill को दोगुना करके $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 देती है। इसलिए 50 percent hit rate पर भी लागत $105.00 रहती है, जो cache के बिना लागत से अधिक है। 90 percent पर दोनों की लागत क्रमशः $21.50 और $29.00 होती है। 99 percent पर short cache $11.15 तक पहुँच जाता है। यह cache के बिना कीमत के एक-दसवें हिस्से की न्यूनतम लागत के करीब है।
Hit rate को instrument करें, क्योंकि prefix size निश्चित हो जाने के बाद यही एकमात्र input है जिसे आप नियंत्रित कर सकते हैं।
किन prefixes पर breakpoint लगाना उपयोगी है
एक request में अधिकतम चार cache breakpoints हो सकते हैं, इसलिए प्रश्न यह है कि किन blocks को एक breakpoint मिलना चाहिए। उम्मीदवार वे blocks हैं जो अलग-अलग calls में byte-identical रहते हैं और इतने बड़े हैं कि उनका प्रभाव पड़े। नीचे दिया गया chart 5 minute cache पर 90 percent hit rate के साथ 1,000 requests के लिए चार सामान्य shapes की लागत दिखाता है।
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 tokens वाला bare system prompt, $7.85 की बचत करता है, जबकि बिना cache के लागत $10.00 होती। बड़े volume पर यह वास्तविक बचत है, लेकिन caching को उपयोगी बनाने वाला मुख्य कारण यह नहीं है। Tool definitions जोड़ने पर कुल आकार 8,000 tokens हो जाता है और $31.40 की बचत होती है। 25,000 tokens वाला policy document, जिसके बारे में हर request में प्रश्न पूछे जाते हैं, $98.12 बचाता है। अंतिम row architecture बदल देती है: codebase या transcript context के 120,000 tokens की लागत बिना cache के $600.00 और cache के साथ $129.00 होती है। इससे $471.00 की बचत होती है।
बचत prefix के आकार और hit rate के साथ बढ़ती है। इसके अलावा किसी अन्य factor से नहीं बढ़ती। इससे यह तय होता है कि prompt में क्या शामिल करना उपयोगी है: Claude tokens की एक million इकाइयों की वास्तविक लागत उन सभी चीजों के लिए सूचीबद्ध कीमत के दसवें हिस्से तक घट जाती है जिन्हें आप एक से अधिक बार भेजते हैं।
मासिक बिल में इसका प्रभाव
नीचे दिया गया chart ऊपर के 8,000 token prefix, एक system prompt और tool definitions को 90 percent 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 की pricing अलग होती है और caching पर इसका कोई प्रभाव नहीं पड़ता। इसलिए किसी को 90 percent bill cut का वादा करने से पहले इसे ध्यान में रखें। Caching उन व्यापक उपायों के साथ काम करती है जो VPS पर AI agent का बिल नियंत्रण में रखते हैं।
Cache के काम करने का प्रमाण कैसे दें
Design पर भरोसा न करें। Response में usage block पढ़ें। प्रत्येक Messages API (application programming interface) reply उन cached tokens की संख्या बताता है जिन्हें उसने लिखा, उन cached tokens की संख्या बताता है जिन्हें उसने पढ़ा, और उन नए tokens की संख्या बताता है जिन्हें उसे process करना पड़ा।
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 और अलग question के साथ दो बार चलाएँ। पहली call में non-zero cache_creation_input_tokens और zero cache_read_input_tokens report होना चाहिए। दूसरी call में इसका उलटा होना चाहिए, क्योंकि prefix मिल गया था। input_tokens केवल last breakpoint के बाद वाले tokens को count करता है। इसलिए सफल दूसरी call में यह छोटा होता है, आम तौर पर केवल नया user message।
आपके द्वारा request.json में save किए गए 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
}एक line वास्तविक स्थिति बताती है। यदि calls के बीच cache_read_input_tokens लगातार 0 रहता है, तो हर बार 1.25x write cost देनी पड़ती है और बदले में कुछ भी वापस नहीं मिलता।
1 hour lifetime के लिए breakpoint में time to live (TTL) होता है:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}Automatic caching भी उपलब्ध है। Request के top level पर एक cache_control field देने के बाद API conversation बढ़ने पर breakpoints को स्वयं manage करता है। यह आपके चार breakpoint slots में से एक slot का उपयोग करता है। शुरुआत इसी से करें। जब boundary का स्थान ठीक-ठीक तय करना हो, तब explicit breakpoints पर जाएँ।
हिट रेट घटाने वाला क्रम नियम
Cache अनुरोध की शुरुआत से byte-by-byte prefix का मिलान करता है। अनुरोध एक निश्चित क्रम में तैयार होता है: पहले tools, फिर system, और अंत में messages। किसी भी स्तर पर बदलाव होने पर वह स्तर और उसके बाद के सभी स्तर invalidate हो जाते हैं। किसी एक tool description को edit करने पर system prompt और पूरा message history भी invalidate हो जाता है, भले ही आपने उनमें कोई बदलाव न किया हो।
इससे एक ऐसा नियम मिलता है जिसका कोई अपवाद नहीं है। Calls के बीच जो भी बदलता है, वह उस हर चीज़ के बाद होना चाहिए जो नहीं बदलती।
आमतौर पर समस्या timestamp से होती है। System prompt के शीर्ष पर Current time: 2026-08-03T14:07:11Z वाली line रखने से hit rate 0 percent हो जाती है, क्योंकि हर call पर prefix hash बदल जाता है और कोई भी पिछली entry उससे match नहीं कर सकती। इसे user message में, अंत में ले जाएँ। Session identifier या per-request nonce भी इसी तरह समस्या पैदा करता है और उसका समाधान भी यही है। हर request में अलग Retrieved documents को भी cached block के बाद रखना चाहिए। अन्यथा वे हर स्थिर token को ऐसे boundary के पीछे धकेल देते हैं जो बदलती रहती है।
दूसरी समस्या बदलने वाले block पर breakpoint रखना है। Cache writes breakpoint पर होती हैं। इसलिए यदि वह block हर बार अलग हो, तो कोई भी स्थिर सामग्री store नहीं होती। Lookback को केवल वे entries मिलती हैं जिन्हें पिछली requests ने अपने-अपने बदलते breakpoints पर लिखा था। cache_control को उस अंतिम block पर रखें जिसकी content सभी requests में समान रहती है।
तीसरी समस्या ऐसा parameter change है जिसे आप prompt content नहीं मानते। अलग model का cache अलग होता है। Tool choice बदलने पर system level से आगे का cache invalidate हो जाता है। किसी tool को जोड़ने या हटाने पर सब कुछ invalidate हो जाता है।
न्यूनतम prefix और शांत no-op
Model की न्यूनतम सीमा से छोटा 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 के दोनों counters में 0 दिखता है, जबकि आपको लगता है कि वह cached है, तो सबसे पहले 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 के बाकी समय पढ़ा जाता है। इसी कारण लंबे session में प्रत्येक turn की लागत context size से दिखाई देने वाली लागत से बहुत कम होती है। यह Claude Code token usage की रिपोर्ट कैसे करता है में बताए गए counters में दिखाई देता है।
जहाँ यह आपकी सहायता नहीं कर सकता, वह context की शुरुआत के पास किया गया edit है। Conversation history केवल append-only होती है, इसलिए सामान्य नए turns पहले से cached prefix को आगे बढ़ाते हैं। Session में पहले पढ़ी गई file को edit करने से उस prefix के बीच का content बदल जाता है, और बदलाव के बाद के प्रत्येक token को फिर से लिखना पड़ता है। लंबा idle gap भी यही प्रभाव डालता है, क्योंकि entry expire हो जाती है और अगला turn पूरा write फिर से करता है। इनमें से कोई भी bug नहीं है। दोनों prefix rule के अनुसार ही काम करते हैं।
यदि आप इसके बजाय अपना client लिख रहे हैं, तो layout को बाद में बदलने के बजाय पहले request से ही लागू करें। Call को उसी तरह बनाएँ, जैसे VPS पर पहला Claude API app में किया गया है: स्थिर blocks पहले और बदलने वाले blocks अंत में रखें।
विफलता की स्थितियाँ और आपको क्या दिखाई देगा
हर call एक write है। प्रत्येक request पर cache_creation_input_tokens non-zero है, जबकि cache_read_input_tokens 0 रहता है। Breakpoint पर या उससे पहले कोई चीज़ calls के बीच बदल रही है। लगातार दो requests पर assembled prefix के पहले 200 characters print करें और उन्हें देखकर तुलना करें।
दोनों counters 0 हैं। Prefix model minimum से छोटा है, या cache_control field API तक कभी पहुँचा ही नहीं। पहले prefix tokens की गिनती करें, फिर उस request body को log करें जिसे आपने वास्तव में भेजा था।
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 uncached requests की लागत N होती है, जबकि N cached 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 से कम है—August 2026 के अनुसार Claude Opus 5 के लिए 512 tokens और Claude Haiku 4.5 के लिए 4,096 tokens—तो caching चुपचाप skip हो जाती है और दोनों counters 0 दिखाते हैं। यदि prefix पर्याप्त लंबा है, तो देखें कि calls के बीच बदलने वाली content breakpoint पर या उससे पहले तो नहीं है। उदाहरण के लिए system prompt में timestamp या session identifier हो सकता है। यदि counters पहले काम कर रहे थे और फिर रुक गए, तो requests के बीच का अंतर cache lifetime से अधिक था।
क्या prompt caching से Claude के answers बदलते हैं?
नहीं। cache आपके पहले भेजे गए tokens का processed form संग्रहीत करती है और model दोनों स्थितियों में वही prompt देखता है। यह billing और latency की सुविधा है, behaviour में बदलाव नहीं। इसका यह भी अर्थ है कि किसी working prompt पर इसे enable करने के लिए evaluations फिर से चलाने की आवश्यकता नहीं है।
क्या मुझे 1 hour cache के लिए भुगतान करना चाहिए?
केवल तब, जब आपके traffic में 5 minutes से अधिक के gaps हों और आपकी hit rate लगभग 53 percent से अधिक बनी रहे। जब cache miss होता है, तो 2x write की अतिरिक्त लागत 1.25x write की तुलना में दोगुनी होती है। 5 minute entry प्रत्येक hit पर refresh होती है। इसलिए steady traffic read prices पर इसे जीवित रखता है और आपको longer lifetime के लिए कभी भुगतान नहीं करना पड़ता।