- लंबे समय तक चलने वाले agent प्रोडक्ट्स में prompt caching एक ऐसी मुख्य तकनीक है जो पिछले roundtrip की computation को दोबारा इस्तेमाल करके latency और cost को नाटकीय रूप से घटाती है, और Claude Code की पूरी architecture इसी के इर्द-गिर्द डिज़ाइन की गई है
- caching prefix matching तरीके से काम करती है, इसलिए static content को आगे और dynamic content को पीछे रखने वाला क्रम cost और performance तय करता है
- session के बीच में tool या model बदलने पर cache invalidate हो जाती है, इसलिए tool हटाने के बजाय lightweight stub और state transition tools का इस्तेमाल करने वाला workaround design ज़रूरी है
- context window पार होने पर किया जाने वाला compaction (summary reduction) भी parent conversation के cache prefix को share करे, वरना cost में विस्फोट हो सकता है
- cache hit rate को uptime की तरह monitor करना चाहिए, और कुछ प्रतिशत cache miss भी cost और latency पर गंभीर असर डालते हैं, इसलिए इन्हें incident की तरह treat करना चाहिए
- “Cache Rules Everything Around Me” agent पर भी वैसे ही लागू होता है
- prompt caching की वजह से Claude Code जैसे long-running agent products संभव हो पाते हैं
- पिछले roundtrip की computation को reuse करके latency और cost में बड़ी कमी आती है
prompt caching कैसे काम करती है और system prompt की placement
- prompt caching prefix matching तरीके से काम करती है, और API request की शुरुआत से हर cache_control breakpoint तक की सारी सामग्री को cache करती है
- requests के बीच shared prefix को maximize करना सबसे अहम है, और इसके लिए static content पहले, dynamic content बाद में रखना चाहिए
- Claude Code का placement order:
- static system prompt और tools (global caching)
- Claude.MD (project-level caching)
- session context (session-level caching)
- conversation messages
- यह क्रम हैरान करने वाली हद तक नाज़ुक है, और
static system prompt में detailed timestamp डालना,
tool order का non-deterministic shuffle होना,
tool parameter update होना
जैसी चीज़ें cache invalidate कर सकती हैं
system message का उपयोग करने वाली update strategy
- ऐसी स्थितियाँ होती हैं जहाँ prompt के अंदर की जानकारी पुरानी हो जाती है, जैसे समय की जानकारी बदलना या user द्वारा files बदलना
- prompt को सीधे update करने पर cache miss होता है, जिससे user cost बढ़ सकती है
- इसके बजाय अगले turn में message के रूप में भेजने का तरीका अपनाया जाता है
- Claude Code अगले user message या tool result में <system-reminder> tag के साथ updated information जोड़ता है
- उदाहरण के लिए “अब Wednesday है” जैसी time update दी जाती है
- इस तरह system messages का उपयोग करके cache को बचाया जा सकता है
session के बीच model क्यों नहीं बदलना चाहिए
- prompt cache हर model के लिए अलग होती है, इसलिए caching cost की गणना अक्सर सहज समझ से अलग हो सकती है
- उदाहरण: Opus में 100k token की conversation के दौरान अगर एक आसान सवाल के लिए Haiku पर switch करें, तो Haiku के लिए cache फिर से शुरू से बनानी पड़ेगी, इसलिए cost उल्टे Opus से जवाब देने से भी ज़्यादा हो सकती है
- अगर model switching ज़रूरी हो, तो subagent तरीका सबसे बेहतर है, जहाँ Opus दूसरे model को "handoff" message तैयार करके देता है
- Claude Code का Explore agent जब Haiku का उपयोग करता है, तो यही तरीका अपनाता है
session के बीच tool जोड़ना या हटाना मना है
- tool set में बदलाव cache invalidation के सबसे आम कारणों में से एक है
- क्योंकि tools cached prefix का हिस्सा होते हैं, इसलिए एक भी tool जोड़ने या हटाने से पूरी conversation की cache invalidate हो जाती है
-
Plan Mode — cache-केंद्रित design
- सहज तरीका: user के plan mode में जाते ही केवल read-only tools छोड़ देना → cache टूट जाती है
- असली design: सभी tools को हमेशा request में शामिल रखना, और EnterPlanMode और ExitPlanMode को tools के रूप में implement करना
- Plan mode में प्रवेश करते समय system message के ज़रिए निर्देश देना: केवल codebase explore करें, file edit न करें, और पूरा होने पर ExitPlanMode call करें
- tool definitions कभी नहीं बदलतीं
- अतिरिक्त लाभ: EnterPlanMode ऐसा tool है जिसे model खुद call कर सकता है, इसलिए कठिन समस्या पहचानने पर अपने-आप plan mode में जा सकता है और cache भी नहीं टूटती
-
Tool Search — हटाने के बजाय lazy loading
- Claude Code में दर्जनों MCP tools load हो सकते हैं; सबको शामिल करने पर cost बढ़ती है और हटाने पर cache टूटती है
- समाधान: defer_loading तरीका, जिसमें tool हटाने के बजाय सिर्फ नाम वाला lightweight stub (
defer_loading: true) भेजा जाता है
- ज़रूरत पड़ने पर model ToolSearch tool के ज़रिए पूरा schema load करता है
- क्योंकि वही stub हमेशा उसी order में मौजूद रहता है, cached prefix स्थिर बना रहता है
- API की tool search feature से इसे सरल बनाया जा सकता है
context forking — compaction
- context window पार होने पर conversation को summarize करके नया session शुरू करने वाला compaction किया जाता है
- सहज implementation (अलग system prompt और tools के बिना अलग API call से summary बनाना) main conversation के cache prefix से बिल्कुल मेल नहीं खाता, इसलिए सभी input tokens पर पूरा cost लगता है
-
Cache-Safe Forking solution
- compaction चलाते समय parent conversation के same system prompt, user context, system context, और tool definitions का उपयोग करें
- parent की conversation messages को आगे रखें, और compaction prompt को अंत में नए user message के रूप में जोड़ें
- API के नज़रिए से यह request parent की आख़िरी request जैसी ही दिखती है, इसलिए cached prefix reuse किया जा सकता है, और नए tokens केवल compaction prompt के होते हैं
- context window के अंदर compacted message और summary output tokens के लिए "compaction buffer" सुरक्षित रखना ज़रूरी है
- इसी pattern के आधार पर Anthropic ने API में सीधे compaction feature built-in किया ताकि developers इसे सीधे इस्तेमाल कर सकें
मुख्य सीख का सार
- prompt caching prefix matching है, और prefix में कहीं भी बदलाव होने पर उसके बाद की सारी cache invalidate हो जाती है → पूरे system को इसी constraint के आसपास design करना चाहिए
- system prompt बदलने के बजाय conversation के दौरान system message insert करना cache बचाने के लिए बेहतर है
- conversation के बीच tool या model न बदलें → state transition को tools के रूप में model करें, और tool removal के बजाय lazy loading का उपयोग करें
- cache hit rate को uptime की तरह monitor करना चाहिए, और कुछ प्रतिशत cache miss rate भी cost और latency पर बहुत बड़ा असर डालती है
- fork operations (compaction, summary, skill execution) को parent prefix share करना चाहिए ताकि cache hit मिल सके
- अगर आप agent बना रहे हैं, तो पहले दिन से prompt caching को केंद्र में रखकर design करना चाहिए
अभी कोई टिप्पणी नहीं है.