Claude Opus 5 च्या नवीन prompt-caching API मुळे चॅट-स्टाईल ॲप्सचे टोकन बिल मोठ्या प्रमाणात कमी होते, कारण हे मॉडेल न बदललेला मजकूर पुन्हा वाचणे टाळू शकते. पहिल्या विनंतीसाठी (request) थोडा जास्त खर्च येतो; त्यानंतरच्या प्रत्येक हिटसाठी मूळ दराच्या साधारण एक-दहावा भाग खर्च येतो, ज्यामुळे वारंवार होणारा खर्च एकावेळच्या शुल्कात रूपांतरित होतो.
डेव्हलपर्सना एकाच शब्दांसाठी दोनदा का पैसे द्यावे लागतात
बहुतेक संवादात्मक इंटरफेस (conversational interfaces) प्रत्येक वेळी पूर्ण प्रॉम्प्ट पुन्हा तयार करतात: ८,०००-टोकनचा सिस्टम प्रॉम्प्ट, जोडलेली PDF आणि संपूर्ण संवादाचा इतिहास, जेव्हा वापरकर्ता फॉलो-अप प्रश्न विचारतो तेव्हा प्रत्येक वेळी मॉडेलकडे पाठवला जातो. मजकुराचा मोठा भाग कधीही बदलत नसतानाही मॉडेल प्रत्येक टोकन पुन्हा प्रोसेस करते. सध्याच्या किंमतीनुसार, या अनावश्यक प्रक्रियेमुळे व्यस्त बॉटचा खर्च खूप वाढू शकतो.
कॅशे (cache) मुळे गणित कसे बदलते
API एका निश्चित ब्रेकपॉइंटपर्यंत (breakpoint) टोकनच्या प्रत्येक "ब्लॉक"साठी कॅशे एन्ट्री तयार करते. जेव्हा पुढची विनंती सुरुवातीला तोच ब्लॉक समाविष्ट असते, तेव्हा सेवा तो पुन्हा टोकनाइझ करण्याऐवजी कॅशेमधून वाचते. किंमतीचे विभाजन वाचलेल्या कामावर आधारित आहे:
- Cache write – 5-minute TTL: 1.25 × base price
- Cache write – 1-hour TTL: 2 × base price
- Cache read (hit): 0.1 × base price
व्यवहारात, नवीन ब्लॉकसाठी केलेली पहिली कॉल सामान्य विनंतीपेक्षा थोडी महाग असते. कॅशे हिट होणारी प्रत्येक नंतरची कॉल ९०% स्वस्त असते, त्यामुळे संवाद जसजसा वाढतो, तसतसा एकूण खर्च झपाट्याने कमी होतो.
प्रॉम्प्ट स्ट्रक्चर करण्यासाठीचा "सुवर्ण नियम"
कॅशेची परिणामकारकता तुम्ही स्थिर (static) आणि डायनॅमिक (dynamic) मजकूर कुठे ठेवता यावर अवलंबून असते. जे काही बदलत नाही ते सर्व सुरुवातीला ठेवा आणि सतत बदलणारे भाग शेवटी ढकलून द्या. एक विश्वसनीय क्रम असा असावा:
- Tools – मॉडेल कॉल करू शकणाऱ्या कोणत्याही बाह्य फंक्शन्सच्या व्याख्या.
- System instructions – मॉडेलने पाळण्याचे तुम्ही इच्छित असलेले उच्च-स्तरीय वर्तन.
- Documents – PDF, नॉलेज बेस किंवा पॉलिसीचे उतारे यांसारखा मोठा संदर्भ (context).
- User questions – प्रत्येक वेळी बदलणारा थेट प्रश्न.
जर तुम्ही ब्रेकपॉइंटपूर्वी कोणताही टोकन बदलला, तर कॅशे एन्ट्री अवैध ठरते आणि मॉडेलला त्यानंतरची सर्व माहिती पुन्हा प्रोसेस करावी लागते.
तुम्हाला पाळायच्या काही लपलेल्या मर्यादा
- Minimum block size – Opus 5 फक्त असे ब्लॉक्स कॅशे करते ज्यामध्ये किमान ५१२ टोकन्स आहेत. त्यापेक्षा लहान काहीही असल्यास ते पूर्णपणे कॅशेच्या बाहेर पडते.
- Timestamp bug – कॅश्ड ब्लॉकच्या आत बदलणारा टाइमस्टॅम्प टाकल्यास कॅशे मिस (miss) होण्याची खात्री असते, कारण ब्लॉकचा मजकूर कधीही तंतोतंत जुळत नाही.
- 20-block look-back – सेवा मॅचसाठी फक्त शेवटचे २० ब्लॉक्स स्कॅन करते. वेगाने पुढे जाणारे दीर्घकालीन सेशन्स कॅशे विंडोच्या बाहेर जाऊ शकतात.
- Parallel requests – एकाच वेळी अनेक सारख्या विनंत्या पाठवल्यास त्या सर्व मिस होतील, कारण पहिली विनंती पूर्ण झाल्यानंतरच कॅशे भरला जातो. प्रथम एका सिंगल कॉलने कॅशे 'वॉर्म' (warm) करा आणि त्यानंतर उर्वरित विनंत्या पाठवा.
तुमच्या API प्रतिसादात (response) बचत पाहणे
प्रत्येक प्रतिसाद तीन टोकन काउंटर्स रिपोर्ट करतो:
cache_read_input_tokens– कॅशे हिटमधून आलेले टोकन्स.cache_creation_input_tokens– या विनंतीमध्ये कॅशेमध्ये लिहिलेले टोकन्स.input_tokens– नवीन टोकन्स जे कॅशे केलेले नव्हते.
त्या टर्नसाठी मॉडेलने विचारात घेतलेले एकूण टोकन्स मिळवण्यासाठी या तीन संख्यांची बेरीज करा. जर दोन्ही कॅशे फील्ड्स शून्य असतील, तर विनंती कॅशे मिस झाली आहे; तुमच्या ब्लॉक साइज आणि ब्रेकपॉइंटच्या स्थानाची तपासणी करा.
थोडक्यात सांगायचे तर (Takeaway): न बदलणारा संदर्भ (immutable context) सुरुवातीला देऊन आणि Claude Opus 5 च्या prompt-caching API ला मुख्य काम करू देऊन, तुम्ही वारंवार होणारा टोकन खर्च एकावेळच्या शुल्कात रूपांतरित करू शकता. याचा परिणाम म्हणजे कोणत्याही चॅटबॉटसाठी खर्चात मोठी घट होते जो वारंवार तोच सिस्टम प्रॉम्प्ट किंवा डॉक्युमेंट सेट वापरतो—जर तुम्ही टोकन फ्लोअरचे पालन केले, कॅश्ड ब्लॉक्समध्ये बदलणारे मार्कर्स टाळले आणि तुमचा कॅशे-योग्य मजकूर २०-ब्लॉकच्या मर्यादेत ठेवला तर.