Coding agents और multi-turn assistants अक्सर वही system prompt, tool definitions और conversation prefix फिर से भेजते हैं। Caching इन दोहराए गए input tokens को सस्ता बना सकती है, लेकिन केवल तब जब model, endpoint और request shape इसका समर्थन करें। इससे generated output पर कोई discount नहीं मिलता, और केवल मिलते-जुलते text को दोहराना पर्याप्त नहीं है यदि cache key बदल जाती है। यह guide OpenAI-style automatic path को Claude के explicit breakpoint behavior से अलग करके समझाती है।
बिल में क्या बदलता है?
Cached read के लिए सामान्य input rate के बजाय cached-input rate से शुल्क लिया जाता है। GetVibe model catalog, model rates के साथ cache support और cache pricing भी प्रकाशित करता है। 3 अक्टूबर 2026 को जाँचे गए catalog snapshot में GPT-6 Luna के लिए $0.0055 इनपुट · $0.0274 आउटपुट प्रति 10 लाख टोकन और Claude Sonnet 5.5 के लिए $0.0534 इनपुट · $0.2667 आउटपुट प्रति 10 लाख टोकन उदाहरण के रूप में शामिल हैं। ये price values live model pages से render होती हैं। वहाँ cache details भी जाँचें; यह न मानें कि हर model एक ही multiplier या write policy का उपयोग करता है।
दोहराए गए prefix का एक सरल अनुमान है: repeated input tokens को normal input rate से गुणा करने पर आने वाली लागत की तुलना repeated input tokens को cache-read rate से गुणा करने पर आने वाली लागत से करें। अंतर संभावित input saving है। यदि वह model cache-write cost लेता है, तो उसे घटाएँ। इस अनुमान को measured result में बदलने के लिए आपके observed request usage की आवश्यकता होती है।
OpenAI-compatible models: prefix को स्थिर रखें
Supported OpenAI-family routes के लिए caching automatic होती है। सामान्य Chat Completions request में जोड़ने के लिए कोई cache-control field नहीं है। दोहराई जाने वाली शुरुआत समान रहनी चाहिए। System instructions, stable examples और tool definitions को user-specific values से पहले रखें। शुरुआत में timestamps, random IDs या per-request feature flags रखने से बचें। Tool order को deterministic रखें।
यदि आप उसी prefix के match होने की अपेक्षा करते हैं, तो agent session जारी रखते समय पहले के conversation turns को rewrite न करें। नए turns append करें। Models बदलने पर अलग model cache शुरू होती है। कोई request valid हो सकती है और फिर भी cached tokens की संख्या शून्य report कर सकती है, क्योंकि prefix model की cache threshold से छोटा है या cache expire हो चुकी है।
Claude: breakpoints और Messages endpoint
Claude caching में cache-control breakpoints का उपयोग होता है। Supported Claude requests में breakpoint मौजूद न होने पर GetVibe integration उसे insert कर सकती है; यदि आप breakpoints स्वयं manage करते हैं, तो वर्तमान caching documentation जाँचें और marker को stable section पर रखें। Claude Code, Anthropic Messages endpoint का उपयोग करता है; Claude Code integration guide में इसका base URL और credentials शामिल हैं।
curl https://getvibeapi.com/v1/messages \
-H "x-api-key: $GETVIBE_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-5.5",
"max_tokens": 300,
"system": [{"type":"text","text":"Stable instructions shared by every request."}],
"messages": [{"role":"user","content":"A request-specific question."}]
}'यह उदाहरण एक stable system section और बदलते हुए user message को दिखाता है। आपके client और model द्वारा समर्थित exact breakpoint field के लिए वर्तमान docs देखें।
Cache hit को मान लेने के बजाय सत्यापित करें
वही long prefix दो बार भेजें और केवल छोटा suffix बदलें। Response usage का निरीक्षण करें। OpenAI-shaped responses cached input को prompt_tokens_details.cached_tokens के अंतर्गत report करते हैं; Anthropic-shaped responses cache read और cache creation fields उपलब्ध कराते हैं। Account usage page पर भी caching information दिखाई जा सकती है। यदि ये counts शून्य बने रहें, तो prefix equality, minimum cacheable length, model support और selected route में हुए किसी बदलाव की जाँच करें।
ऐसा sample उपयोग करें जो model की cache threshold से अधिक बड़ा हो। एक वाक्य वाला system prompt शायद दिखाई देने वाला अंतर न पैदा करे। कई repeated calls की तुलना करें, क्योंकि cache lifetime और request scheduling यह प्रभावित करते हैं कि prefix अभी warm है या नहीं।
बचत का व्यावहारिक परीक्षण
- एक ऐसा real prompt चुनें जिसमें पर्याप्त बड़ा reusable prefix हो।
- उसका ordinary input usage और वर्तमान model-page rates record करें।
- केवल user suffix बदलकर उसे दोहराएँ।
- पुष्टि करें कि response cached input report करता है।
- Repeated requests की ledger cost की तुलना करें।
Experiment के दौरान output length को समान रखें, ताकि output spend input change को अस्पष्ट न कर दे। केवल cache multiplier के आधार पर savings का दावा न करें; cache-hit count और billed usage को सत्यापित करें।
सामान्य cache misses
- Stable instructions से पहले timestamp या request ID मौजूद है।
- हर request में tool definitions को अलग order में serialize किया जाता है।
- Application whitespace बदलती है या history को अलग तरीके से truncate करती है।
- Turns के बीच model बदल जाता है।
- Prefix बहुत छोटा है या cache window समाप्त हो गई है।
जब caching काम करती है, तो यह लंबे agent conversations को अधिक किफायती बना सकती है, लेकिन यह अनावश्यक repository context भेजने का कारण नहीं है। Prompts को focused रखें और total task cost का मूल्यांकन करें। अधिक गहरे endpoint details के लिए caching implementation guide और model का live price page पढ़ें।
Breakpoints वहाँ रखें जहाँ उनका फिर से उपयोग हो सके
Messages-format prompt के लिए stable instructions और reference material को system block में रखें, फिर बदलते हुए question को user message में रखें। Cache breakpoint stable portion के अंत में होना चाहिए, request-specific timestamp के बाद नहीं। यदि context में कई बड़े documents हैं, तो calls के बीच reuse होने वाले portions में breakpoints रखें और model द्वारा समर्थित breakpoint count को verify करें।
उन agents से सावधान रहें जो अपनी history का स्वयं summary बनाते हैं। यदि हर turn पिछली conversation को rewrite करता है, तो prefix बदल जाता है और cache hit गायब हो सकता है, भले ही पूरी conversation किसी व्यक्ति को समान दिखे। Miss को debug करते समय serialized request body की तुलना करें, और private content को logs से बाहर रखें।
Cache writes और minimum lengths का हिसाब रखें
कुछ models में caching लागू होने से पहले minimum prefix length आवश्यक होती है, और पहली write का billing बाद के read से अलग हो सकता है। इसलिए छोटा prompt कोई saving नहीं दिखा सकता। वर्तमान model के cache read और write prices तथा cacheable token threshold जाँचें। फिर first request की तुलना subsequent requests से अलग-अलग करें, बजाय इसके कि उन्हें एक अस्पष्ट संख्या में average कर दें।
Cache availability समय पर निर्भर करती है। Idle period के बाद prefix expire हो सकता है, और cache application data के लिए durable store नहीं है। Conversation state को सुरक्षित रखने के लिए कभी भी इस पर निर्भर न रहें; सही answer के लिए आवश्यक context भेजना जारी रखें।
Cache savings को prompt optimization से अलग रखें
Duplicated context को कम करना और repeated context को cache करना दो अलग improvements हैं। पहले irrelevant instructions, stale examples और copied logs हटाएँ। फिर बचे हुए stable material को cache करें। इससे cache miss होने पर भी prompt छोटा रहता है और unused context के लिए बार-बार भुगतान करने से बचा जा सकता है।
Prompt change का मूल्यांकन करते समय task examples को समान रखें। छोटा prefix cost कम कर सकता है, लेकिन model के लिए आवश्यक information भी हटा सकता है। Output quality का मूल्यांकन cached और uncached usage के साथ करें, ताकि optimization अनजाने में correctness से समझौता न करे।