एजेंट लूप का ख़र्च «एक कॉल गुणा बारियों की संख्या» नहीं है, और फ़र्क़ छोटा नहीं। API की कोई स्मृति नहीं, इसलिए हर बारी पहले का सब कुछ दोबारा भेजती है: सिस्टम प्रॉम्प्ट, उपकरण परिभाषाएँ, और हर संदेश तथा उपकरण का नतीजा। आठवीं बारी वह सब भेजती है जो पहली से सातवीं ने भेजा, साथ में वह भी जो उन्होंने बनाया। इससे ख़र्च बातचीत की लंबाई के साथ नहीं, उसके वर्ग के साथ बढ़ता है — इसीलिए जो लूप आज़माने में सस्ते लगते हैं वे होते नहीं। यहाँ लूप बारी-दर-बारी चलाया जाता है, कैश वहीं लगाई जाती है जहाँ वह सचमुच लगती है, और वह बारी नामित होती है जिस पर विंडो भर जाती है।
विशेषताएँ
हर बारी अलग से आँकी जाती है, दोबारा भेजे इतिहास समेत
कैश सिर्फ़ स्थिर उपसर्ग पर लागू — यही ईमानदार मॉडल है
तुलना के लिए वही लूप बिना कैश के भी आँका जाता है
सिर्फ़ स्मृतिहीनता की वजह से दोबारा भेजे टोकन गिनता है
वह बारी नामित करता है जिस पर संदर्भ विंडो भर जाती है
थोक दर एक स्विच से
बारी-दर-बारी दंड-चित्र, ताकि बढ़त दिखे
जाँच की तिथि के साथ दरें
एजेंट लूप ख़र्च अनुमान का उपयोग कैसे करें
मॉडल और अपेक्षित बारियाँ चुनिए
स्थिर उपसर्ग, आउटपुट और उपकरण नतीजों के आकार भरिए
यथार्थवादी कैश हिट दर तय कीजिए
कुल, बचत और भर जाने का बिंदु पढ़िए
उदाहरण
इनपुट
8 turns, 4K prefix, 1.5K tool results
आउटपुट
Turn 8 sends 19.4K tokens — turn 1 sent 4.5K
बढ़ता इतिहास है, काम नहीं।
सामान्य त्रुटियाँ और समस्या निवारण
मेरा असली बिल इससे ज़्यादा है। — आम तौर पर उपकरण के नतीजे: वही सबसे बड़ा और सबसे कम अनुमानित इनपुट हैं। सामान्य नहीं, सबसे बड़े नतीजे का आकार लीजिए।
कैश की बचत बहुत अच्छी लग रही है। — सिर्फ़ स्थिर उपसर्ग को कैश योग्य माना जाता है, जो पहले से ही सतर्क मान्यता है। आपका उपसर्ग बारियों के बीच बदलता हो तो हिट दर घटाइए।
कहता है विंडो भर जाती है। — लूप ख़त्म होने से पहले बातचीत मॉडल से बड़ी हो जाती है। संपीड़न, संदर्भ का संपादन, या उपकरण नतीजों का आकार घटाना — असर के इसी क्रम में।
अपने टोकन आकार कैसे जानूँ? — एक असली बारी टोकन काउंटर से नापिए और वही आँकड़े लीजिए। जवाब का आकार सटीकता से ज़्यादा मायने रखता है।
अक्सर पूछे जाने वाले प्रश्न
वही काम एक कॉल में करने से लूप महँगा क्यों है?
क्योंकि हर बारी पूरी बातचीत दोबारा भेजती है। दस बारियाँ यानी दस इनपुट कॉल नहीं, बल्कि बढ़ती हुई बातचीत का जोड़ — इसीलिए ख़र्च की रेखा ऊपर मुड़ती है।
ख़र्च सबसे ज़्यादा क्या बढ़ाता है?
उपकरण नतीजों का आकार, आम तौर पर बड़े अंतर से। आउटपुट टोकन प्रति नग महँगे हैं पर बहुत कम होते हैं; हर बारी एक पन्ना JSON लौटाने वाला बातूनी उपकरण ही सस्ते लूप को महँगा बना देता है।
क्या 90% हिट दर यथार्थवादी है?
स्थिर सिस्टम प्रॉम्प्ट और तय उपकरण सूची के लिए हाँ। उपसर्ग में कुछ भी प्रति-अनुरोध बदलता हो तो वह शून्य के क़रीब है; यह पता करने में कैश योजना मदद करती है।
क्या थोक दर लेनी चाहिए?
सिर्फ़ तब जब काम अन्तःक्रियात्मक न हो। वह बिल आधा कर देती है और बीच में दख़ल देने की गुंजाइश ले लेती है, जो मूल्यांकन और थोक प्रसंस्करण के लिए ठीक है, किसी प्रतीक्षारत एजेंट के लिए नहीं।
यह कितना सटीक है?
यह एक मॉडल है, कोई कोटेशन नहीं। यह आपके आँकड़ों से सही आकार बताता है — बढ़त, कैश का असर, भर जाने का बिंदु। प्रकाशित दरें बदलती हैं, इसलिए जाँच की तिथि साथ दिखती है।
संबंधित टूल
प्रॉम्प्ट कैश योजना — ब्लॉक ऐसे क्रम में रखिए कि कैश होने वाला उपसर्ग सबसे लंबा हो।
संदर्भ विंडो योजना — विंडो को प्रॉम्प्ट, उपकरण, इतिहास और जवाब में बाँटिए।
थोक अनुरोध बिल्डर — पंक्तियों की तालिका को अलग पहचान वाले थोक कार्य में बदलिए।
LLM Cost Calculator — अपनी टोकन गिनती से GPT, Claude और Gemini API लागत का अनुमान लगाएँ।