अक्सर इंजीनियरिंग में कहा जाता है कि "Cache Rules Everything Around Me", और एजेंटों के लिए भी यही नियम लागू होता है।
Claude Code जैसे लंबे समय तक चलने वाले एजेंटिक उत्पाद प्रॉम्प्ट कैशिंग की बदौलत संभव हो पाते हैं, जो हमें पिछले राउंडट्रिप के कम्प्यूटेशन को पुनः उपयोग करने और लेटेंसी तथा लागत को काफी कम करने की अनुमति देता है।
प्रॉम्प्ट कैशिंग क्या है, यह कैसे काम करती है और आप इसे तकनीकी रूप से कैसे लागू करते हैं? @RLanceMartin के प्रॉम्प्ट कैशिंग और हमारे नए ऑटो-कैशिंग लॉन्च पर लेख में और पढ़ें।
Claude Code में, हम अपना पूरा हार्नेस प्रॉम्प्ट कैशिंग के आसपास बनाते हैं। उच्च प्रॉम्प्ट कैश हिट रेट लागत कम करता है और हमारी सब्सक्रिप्शन योजनाओं के लिए अधिक उदार दर सीमाएँ बनाने में मदद करता है, इसलिए हम अपनी प्रॉम्प्ट कैश हिट रेट पर अलर्ट चलाते हैं और यदि वे बहुत कम हैं तो SEV घोषित करते हैं।
ये वे (अक्सर अंतर्ज्ञान के विपरीत) सबक हैं जो हमने बड़े पैमाने पर प्रॉम्प्ट कैशिंग को ऑप्टिमाइज़ करने से सीखे हैं।
कैशिंग के लिए अपना प्रॉम्प्ट व्यवस्थित करें
प्रॉम्प्ट कैशिंग उपसर्ग मिलान द्वारा काम करती है — API अनुरोध की शुरुआत से प्रत्येक cache_control ब्रेकपॉइंट तक सब कुछ कैश करता है। इसका मतलब है कि आप जिस क्रम में चीज़ें रखते हैं, वह बहुत मायने रखता है, आप चाहते हैं कि आपके अधिक से अधिक अनुरोध एक उपसर्ग साझा करें।
ऐसा करने का सबसे अच्छा तरीका है पहले स्थिर सामग्री, फिर गतिशील सामग्री। Claude Code के लिए यह इस प्रकार दिखता है:
- स्थिर सिस्टम प्रॉम्प्ट और टूल्स (वैश्विक रूप से कैश्ड)
- Claude.MD (एक प्रोजेक्ट के भीतर कैश्ड)
- सत्र संदर्भ (एक सत्र के भीतर कैश्ड)
- बातचीत संदेश
इस तरह हम अधिकतम करते हैं कि कितने सत्र कैश हिट साझा करते हैं।
लेकिन यह आश्चर्यजनक रूप से नाजुक हो सकता है! इस क्रम को तोड़ने के कारणों के उदाहरणों में शामिल हैं: स्थिर सिस्टम प्रॉम्प्ट में एक गहन टाइमस्टैम्प डालना, गैर-निर्धारणीय रूप से टूल ऑर्डर परिभाषाओं को फेरबदल करना, टूल के पैरामीटर अपडेट करना (जैसे AgentTool किन एजेंटों को कॉल कर सकता है), आदि।
अपडेट के लिए संदेशों का उपयोग करें
कई बार ऐसा हो सकता है कि आपके प्रॉम्प्ट में दी गई जानकारी पुरानी हो जाए, उदाहरण के लिए यदि आपके पास समय है या उपयोगकर्ता कोई फ़ाइल बदलता है। प्रॉम्प्ट को अपडेट करना आकर्षक लग सकता है, लेकिन इसके परिणामस्वरूप कैश मिस हो सकता है और उपयोगकर्ता के लिए काफी महंगा साबित हो सकता है।
विचार करें कि क्या आप इस जानकारी को अगले टर्न में संदेशों के माध्यम से पास कर सकते हैं। Claude Code में, हम अगले उपयोगकर्ता संदेश या टूल परिणाम में मॉडल के लिए अपडेट की गई जानकारी (जैसे अब बुधवार है) के साथ एक <system-reminder> टैग जोड़ते हैं, जो कैश को संरक्षित करने में मदद करता है।
सत्र के बीच में मॉडल न बदलें
प्रॉम्प्ट कैश मॉडल के लिए अद्वितीय होते हैं और यह प्रॉम्प्ट कैशिंग के गणित को काफी अंतर्ज्ञान के विपरीत बना सकता है।
यदि आप Opus के साथ 100k टोकन की बातचीत में हैं और एक ऐसा प्रश्न पूछना चाहते हैं जिसका उत्तर देना काफी आसान है, तो Haiku पर स्विच करना वास्तव में Opus से उत्तर दिलाने की तुलना में अधिक महंगा होगा, क्योंकि हमें Haiku के लिए प्रॉम्प्ट कैश को फिर से बनाना होगा।
यदि आपको मॉडल बदलने की आवश्यकता है, तो ऐसा करने का सबसे अच्छा तरीका सबएजेंटों के साथ है, जहाँ Opus एक अन्य मॉडल को उस कार्य पर एक "हैंडऑफ़" संदेश तैयार करेगा जिसे करने की आवश्यकता है। हम Claude Code में एक्सप्लोर एजेंटों के साथ ऐसा अक्सर करते हैं जो Haiku का उपयोग करते हैं।
सत्र के बीच में कभी भी टूल न जोड़ें या न हटाएं
बातचीत के बीच में टूल सेट को बदलना सबसे आम तरीकों में से एक है जिससे लोग प्रॉम्प्ट कैशिंग को तोड़ते हैं। यह सहज लगता है — आपको मॉडल को केवल वे टूल देना चाहिए जो आपको लगता है कि अभी इसकी आवश्यकता है। लेकिन चूंकि टूल कैश्ड उपसर्ग का हिस्सा हैं, एक टूल को जोड़ने या हटाने से पूरी बातचीत के लिए कैश अमान्य हो जाता है।
प्लान मोड — कैश के आसपास डिज़ाइन करें
प्लान मोड कैशिंग बाधाओं के आसपास सुविधाओं को डिज़ाइन करने का एक बेहतरीन उदाहरण है। सहज दृष्टिकोण होगा: जब उपयोगकर्ता प्लान मोड में प्रवेश करता है, तो टूल सेट को केवल रीड-ओनली टूल शामिल करने के लिए बदल दें। लेकिन इससे कैश टूट जाएगा।
इसके बजाय, हम अनुरोध में सभी टूल को हर समय रखते हैं और EnterPlanMode और ExitPlanMode को स्वयं टूल के रूप में उपयोग करते हैं। जब उपयोगकर्ता प्लान मोड को टॉगल करता है, तो एजेंट को एक सिस्टम संदेश मिलता है जो बताता है कि यह प्लान मोड में है और निर्देश क्या हैं — कोडबेस का अन्वेषण करें, फ़ाइलों को संपादित न करें, जब योजना पूरी हो जाए तो ExitPlanMode को कॉल करें। टूल परिभाषाएँ कभी नहीं बदलती हैं।
इसका एक अतिरिक्त लाभ है: क्योंकि EnterPlanMode एक टूल है जिसे मॉडल स्वयं कॉल कर सकता है, यह बिना कैश ब्रेक के, एक कठिन समस्या का पता लगाने पर स्वायत्त रूप से प्लान मोड में प्रवेश कर सकता है।
टूल सर्च — हटाने के बजाय स्थगित करें
यही सिद्धांत हमारी टूल सर्च सुविधा पर भी लागू होता है। Claude Code में दर्जनों MCP टूल लोड हो सकते हैं, और उन सभी को हर अनुरोध में शामिल करना महंगा होगा। लेकिन बातचीत के बीच में उन्हें हटाने से कैश टूट जाएगा।
हमारा समाधान: defer_loading। टूल को हटाने के बजाय, हम हल्के स्टब भेजते हैं — केवल टूल का नाम, defer_loading: true के साथ — जिसे मॉडल आवश्यकता पड़ने पर ToolSearch टूल के माध्यम से "खोज" सकता है। पूर्ण टूल स्कीमा केवल तभी लोड होते हैं जब मॉडल उनका चयन करता है। यह कैश्ड उपसर्ग को स्थिर रखता है: समान स्टब हमेशा समान क्रम में मौजूद होते हैं।
सौभाग्य से, आप इसे सरल बनाने के लिए अपने API के माध्यम से टूल सर्च टूल का उपयोग कर सकते हैं।
संदर्भ को फोर्क करना — संघनन
संघनन तब होता है जब आप संदर्भ विंडो से बाहर हो जाते हैं। हम अब तक की बातचीत को सारांशित करते हैं और उस सारांश के साथ एक नया सत्र जारी रखते हैं।
हैरानी की बात है कि संघनन में प्रॉम्प्ट कैशिंग के साथ कई एज केस होते हैं जो अंतर्ज्ञान के विपरीत हो सकते हैं।
विशेष रूप से, जब हम संघनन करते हैं तो हमें सारांश उत्पन्न करने के लिए मॉडल को पूरी बातचीत भेजने की आवश्यकता होती है। यदि यह एक अलग सिस्टम प्रॉम्प्ट के साथ और बिना किसी टूल के एक अलग API कॉल है (जो सरल कार्यान्वयन है), तो मुख्य बातचीत से कैश्ड उपसर्ग बिल्कुल मेल नहीं खाता। आप उन सभी इनपुट टोकन के लिए पूरी कीमत चुकाते हैं, जिससे उपयोगकर्ता के लिए लागत नाटकीय रूप से बढ़ जाती है।
समाधान — कैश-सुरक्षित फोर्किंग
जब हम संघनन चलाते हैं, तो हम मूल बातचीत के बिल्कुल समान सिस्टम प्रॉम्प्ट, उपयोगकर्ता संदर्भ, सिस्टम संदर्भ और टूल परिभाषाओं का उपयोग करते हैं। हम मूल बातचीत के संदेशों को प्रीपेंड करते हैं, फिर अंत में एक नए उपयोगकर्ता संदेश के रूप में संघनन प्रॉम्प्ट जोड़ते हैं।
API के दृष्टिकोण से, यह अनुरोध मूल के अंतिम अनुरोध के लगभग समान दिखता है — समान उपसर्ग, समान टूल, समान इतिहास — इसलिए कैश्ड उपसर्ग का पुन: उपयोग होता है। केवल नए टोकन स्वयं संघनन प्रॉम्प्ट हैं।
हालाँकि, इसका मतलब यह है कि हमें एक "संघनन बफर" को सहेजने की आवश्यकता है ताकि संदर्भ विंडो में संघनित संदेश और सारांश आउटपुट टोकन शामिल करने के लिए पर्याप्त जगह हो।
संघनन मुश्किल है, लेकिन सौभाग्य से, आपको ये सबक खुद सीखने की आवश्यकता नहीं है — हमने Claude Code से अपनी सीख के आधार पर API में सीधे संघनन का निर्माण किया है, ताकि आप इन पैटर्न को अपने स्वयं के अनुप्रयोगों में लागू कर सकें।
सीखे गए सबक
- प्रॉम्प्ट कैशिंग एक उपसर्ग मिलान है। उपसर्ग में कहीं भी कोई भी परिवर्तन उसके बाद की सभी चीज़ों को अमान्य कर देता है। इस बाधा के आसपास अपने पूरे सिस्टम को डिज़ाइन करें। क्रम को सही रखें और अधिकांश कैशिंग मुफ्त में काम करेगी।
- सिस्टम प्रॉम्प्ट बदलने के बजाय संदेशों का उपयोग करें। प्लान मोड में प्रवेश करना, तारीख बदलना आदि जैसे काम करने के लिए आप सिस्टम प्रॉम्प्ट को संपादित करने के लिए प्रलोभित हो सकते हैं, लेकिन बातचीत के दौरान इन्हें संदेशों में सम्मिलित करना वास्तव में बेहतर होगा।
- बातचीत के बीच में टूल या मॉडल न बदलें। टूल सेट बदलने के बजाय स्थिति संक्रमण (जैसे प्लान मोड) को मॉडल करने के लिए टूल का उपयोग करें। टूल को हटाने के बजाय उन्हें लोड करना स्थगित करें।
- अपनी कैश हिट रेट की निगरानी वैसे ही करें जैसे आप अपटाइम की करते हैं। हम कैश ब्रेक पर अलर्ट करते हैं और उन्हें घटनाओं के रूप में मानते हैं। कैश मिस दर के कुछ प्रतिशत अंक लागत और लेटेंसी को नाटकीय रूप से प्रभावित कर सकते हैं।
- फोर्क संचालन को मूल के उपसर्ग को साझा करने की आवश्यकता होती है। यदि आपको एक साइड कम्प्यूटेशन (संघनन, सारांशीकरण, कौशल निष्पादन) चलाने की आवश्यकता है, तो समान कैश-सुरक्षित पैरामीटर का उपयोग करें ताकि आपको मूल के उपसर्ग पर कैश हिट मिले।
Claude Code पहले दिन से प्रॉम्प्ट कैशिंग के आसपास बनाया गया है, यदि आप एक एजेंट बना रहे हैं तो आपको भी ऐसा ही करना चाहिए।
