Claude Opus 5 का नया prompt-caching API चैट-शैली वाले ऐप्स के टोकन बिलों में भारी कटौती करता है, क्योंकि यह मॉडल को बिना बदले हुए टेक्स्ट को दोबारा पढ़ने से बचने की अनुमति देता है। पहला अनुरोध एक मामूली प्रीमियम के साथ आता है; इसके बाद का हर हिट मूल दर का लगभग दसवां हिस्सा खर्च करता है, जिससे एक आवर्ती खर्च एकमुश्त शुल्क में बदल जाता है।
डेवलपर्स एक ही शब्दों के लिए दो बार भुगतान क्यों करते हैं
अधिकांश संवादात्मक इंटरफेस (conversational interfaces) हर बार पूरा प्रॉम्प्ट फिर से बनाते हैं: एक 8,000-टोकन वाला सिस्टम प्रॉम्प्ट, अटैच की गई PDF, और पूरा संवाद इतिहास, हर बार जब कोई उपयोगकर्ता फॉलो-अप प्रश्न पूछता है, तो मॉडल के पास एक साथ भेजे जाते हैं। मॉडल हर टोकन को फिर से प्रोसेस करता है, भले ही उस टेक्स्ट का अधिकांश हिस्सा कभी बदलता ही नहीं है। वर्तमान कीमतों पर, यह अतिरेक (redundancy) एक व्यस्त बॉट की लागत पर हावी हो सकता है।
कैश कैसे गणित बदल देता है
API एक निर्धारित ब्रेकपॉइंट तक टोकन के प्रत्येक "ब्लॉक" के लिए एक कैश एंट्री बनाता है। जब अगले अनुरोध में शुरुआत में वही ब्लॉक होता है, तो सेवा उसे फिर से टोकनाइज़ करने के बजाय कैश से पढ़ती है। मूल्य विभाजन बचाए गए कार्य को दर्शाता है:
- Cache write – 5-minute TTL: 1.25 × मूल कीमत
- Cache write – 1-hour TTL: 2 × मूल कीमत
- Cache read (hit): 0.1 × मूल कीमत
व्यवहार में, एक नए ब्लॉक के लिए पहला कॉल सामान्य अनुरोध से थोड़ा अधिक महंगा होता है। बाद में किया गया हर कॉल जो कैश को हिट करता है, वह 90% सस्ता होता है, इसलिए जैसे-जैसे बातचीत गहरी होती है, कुल खर्च तेजी से कम हो जाता है।
प्रॉम्प्ट को स्ट्रक्चर करने का "गोल्डन रूल"
कैश की प्रभावशीलता इस बात पर निर्भर करती है कि आप स्टैटिक (स्थिर) बनाम डायनेमिक (गतिशील) कंटेंट कहाँ रखते हैं। जो चीज़ें समान रहती हैं उन्हें शुरुआत में रखें, और जो लगातार बदलती रहती हैं उन्हें अंत में रखें। एक विश्वसनीय क्रम इस प्रकार है:
- Tools – किसी भी बाहरी फंक्शन की परिभाषा जिसे मॉडल कॉल कर सकता है।
- System instructions – वह उच्च-स्तरीय व्यवहार जिसका मॉडल को पालन करना चाहिए।
- Documents – लंबा संदर्भ जैसे PDF, नॉलेज बेस, या पॉलिसी के अंश।
- User questions – लाइव क्वेरी जो हर बार बदलती है।
यदि आप ब्रेकपॉइंट से पहले किसी भी टोकन को संशोधित करते हैं, तो कैश एंट्री अमान्य हो जाती है और मॉडल को उसके बाद की हर चीज़ को फिर से प्रोसेस करना पड़ता है।
छिपी हुई सीमाएँ जिनका आपको ध्यान रखना चाहिए
- न्यूनतम ब्लॉक आकार (Minimum block size) – Opus 5 केवल उन्हीं ब्लॉक्स को कैश करता है जिनमें कम से कम 512 टोकन होते हैं। इससे छोटा कुछ भी पूरी तरह से कैश से बाहर रह जाता है।
- टाइमस्टैम्प बग (Timestamp bug) – कैश किए गए ब्लॉक के अंदर बदलता हुआ टाइमस्टैम्प डालने से कैश मिस होना तय है, क्योंकि ब्लॉक का टेक्स्ट कभी भी बिल्कुल मेल नहीं खाता।
- 20-ब्लॉक लुक-बैक (20-block look-back) – सेवा मैच के लिए केवल पिछले 20 ब्लॉक्स को स्कैन करती है। लंबे समय तक चलने वाले सत्र जो तेजी से आगे बढ़ जाते हैं, वे कैश विंडो से बाहर निकल सकते हैं।
- पैरेलल अनुरोध (Parallel requests) – एक ही समय पर कई समान अनुरोध भेजने पर वे सभी मिस हो जाएंगे, क्योंकि कैश केवल पहले अनुरोध के पूरा होने के बाद ही भरा जाता है। कैश को एक सिंगल कॉल से वार्म अप करें, फिर बाकी अनुरोध जारी करें।
अपने API रिस्पॉन्स में बचत देखें
प्रत्येक रिस्पॉन्स तीन टोकन काउंटर रिपोर्ट करता है:
cache_read_input_tokens– वे टोकन जो कैश हिट से आए थे।cache_creation_input_tokens– इस अनुरोध में कैश में लिखे गए टोकन।input_tokens– नए टोकन जो कैश नहीं किए गए थे।
उस टर्न के लिए मॉडल द्वारा विचार किए गए कुल टोकन प्राप्त करने के लिए तीनों संख्याओं को जोड़ें। यदि दोनों कैश फ़ील्ड शून्य हैं, तो अनुरोध कैश मिस हो गया है; अपने ब्लॉक आकार और ब्रेकपॉइंट प्लेसमेंट की जाँच करें।
निष्कर्ष: इम्यूटेबल (अपरिवर्तनीय) संदर्भ को आगे रखकर और Claude Opus 5 के prompt-caching API को भारी काम करने देकर, आप आवर्ती टोकन खर्च को एकमुश्त शुल्क में बदल देते हैं। इसका परिणाम किसी भी चैटबॉट के लिए लागत में भारी कमी है जो बार-बार एक ही सिस्टम प्रॉम्प्ट या दस्तावेज़ सेट का संदर्भ देता है—बशर्ते आप टोकन फ्लोर का सम्मान करें, कैश किए गए ब्लॉक्स के अंदर परिवर्तनीय मार्कर से बचें, और अपने कैश-योग्य कंटेंट को 20-ब्लॉक की सीमा के भीतर रखें।