Claude Code को गंभीरता से इस्तेमाल करना शुरू करेंगे तो "सीमा तक पहुँच गए" से मुलाक़ात होगी ही। यह अध्याय उसी से बचने के संचालन की बात करता है।
लेकिन मक़सद बचत ख़ुद नहीं है। मक़सद है ऐसी हालत बनाना जिसमें ऐन ज़रूरत के वक़्त कोटा बचा हो। कंजूसी करके नतीजा गिर जाए तो सारा मामला उलटा पड़ जाता है, इसलिए आख़िर में हम लकीर खींचने की बात भी करेंगे।
खपत बढ़ती क्यों है
खपत की इकाई टोकन है। यहाँ ज़्यादातर लोग जिस बात पर धोखा खाते हैं वह यह है कि यह सिर्फ़ "आपने जो निर्देश भेजा उसकी लंबाई" से तय नहीं होती।
Claude ने जो फ़ाइलें ख़ुद जाकर पढ़ीं, वे सब इनपुट में चढ़ जाती हैं। कोई बड़ी फ़ाइल पूरी-की-पूरी पढ़वा दें तो यह एक झटके में बढ़ जाती है।
हर आवाजाही के साथ अब तक का इतिहास भी साथ भेजा जाता है। लंबी बातचीत में हर एक चक्कर की क़ीमत बढ़ जाती है।
टेस्ट पास होने तक सुधारते रहने वाली हरकत, हर नाकामी पर एक चक्कर जितनी खपत करती है। यह उसी ताक़त का दूसरा पहलू है।
इन तीनों में से आपके हाथ में सबसे ज़्यादा FACTOR 2 है। कौन-सी फ़ाइलें पढ़ी जाएँगी यह काम की सामग्री तय करती है, और कोशिशों की गिनती कठिनाई तय करती है, लेकिन इतिहास की लंबाई आप अपने संचालन से बदल सकते हैं।
"छोटा निर्देश देंगे तो सस्ता पड़ेगा" एक ग़लतफ़हमी है। निर्देश इतना छोटा हो कि मंशा ही न पहुँचे, तो Claude खोज बढ़ा देता है, निशाने से चूका हुआ इम्प्लीमेंटेशन बनाता है, और फिर दोबारा करता है। नतीजा यह कि चक्कर बढ़ जाते हैं और बात महँगी पड़ती है। सस्ता छोटा निर्देश नहीं, वह निर्देश है जो एक ही बार में पार हो जाए।
कोटा एक ही तरह का नहीं होता
अध्याय 4 में भी इसका ज़िक्र आया था, पर संचालन की असली समझ यहीं है। छोटे चक्र वाला कोटा और लंबे चक्र वाला कोटा, दोनों अलग-अलग मौजूद हैं।
छोटा वाला अपेक्षाकृत जल्दी बहाल हो जाता है, इसलिए थोड़ा रुककर काम दोबारा शुरू किया जा सकता है। लंबे वाले की बहाली में दिन लगते हैं, और उसे ख़त्म कर देने पर आप कई दिन हिल भी नहीं पाएँगे। "अभी तो वापस चालू हुआ था और फ़ौरन फिर रुक गया" वाला अनुभव उसी हालत का है जिसमें सिर्फ़ छोटा वाला लौटा और लंबा वाला बचा ही रहा।
कोटा किस तरह बर्ताव करता है यह usage limit reached का इलाज में है, और साप्ताहिक कोटा उम्मीद से जल्दी लौट आने की परिघटना को नाप-तौलकर देखा गया नतीजा साप्ताहिक सीमा के जल्दी रीसेट होने की असलियत में समेटा गया है।
डेडलाइन से पहले वाले भारी काम पहले निपटा लीजिए, और खोजबीन वाले प्रयोग उन घंटों में कीजिए जब कोटे में गुंजाइश हो।
लंबे कोटे को आज़माइश में ख़त्म कर देना, और असली काम वाले दिन हिल भी न पाना। फिर बहाली का इंतज़ार करने के सिवा कुछ नहीं बचता।
effort ― तेज़ी और अक़्ल में से चुनना
Claude Code में एक ऐसी सेटिंग है जिससे आप चुनते हैं कि उससे कितना सोचवाना है। गहरा सोचवाएँगे तो सटीकता बढ़ेगी, पर उतना ही समय और उतनी ही खपत भी बढ़ेगी।
यहाँ "हमेशा अधिकतम" रखने में भी घाटा है और "हमेशा न्यूनतम" रखने में भी। सही जवाब है काम की कठिनाई के हिसाब से बदलते रहना।
तयशुदा बदलाव, फ़ॉर्मैटिंग, टेस्ट जोड़ना, और वह इम्प्लीमेंटेशन जिसकी दिशा पहले से तय है। वे काम जिनमें सोचने की गुंजाइश ही नहीं।
वह बग जिसका कारण समझ नहीं आ रहा, डिज़ाइन का चुनाव, और वह बदलाव जिसका असर कहाँ तक जाएगा पता नहीं। वे काम जिनमें ग़लती हुई तो पीछे लौटना भारी पड़ता है।
इस सेटिंग के भीतर क्या है और उसे कब कैसे बदलना है, यह effort क्या है? तेज़ और अक़्लमंद के बीच चुनाव में देखा गया है। परखने की धुरी है पीछे लौटने की लागत से तुलना करना। गहरा सोचवाकर बात एक ही बार में बन जाए, तो यह हल्का रखकर तीन बार दोहराने से सस्ता ही पड़ता है।
कॉन्टेक्स्ट समेटना लागत की भी बात है
अध्याय 3 में हमने इसे इस संदर्भ में देखा था कि "याद नहीं रह पाता इसलिए समेटिए", लेकिन समेटने की एक वजह और भी है। लंबा इतिहास हर बार भेजा जाता है, इसलिए बिना समेटे काम चलाते रहेंगे तो हर एक चक्कर की खपत लगातार फूलती जाएगी।
फिर भी, समेटने की भी अपनी खपत है। ज़रूरत से ज़्यादा समेट देंगे तो वे मान्यताएँ भी चली जाएँगी जो चाहिए थीं, और दोबारा समझाना पड़ेगा ― यह उलटा महँगा पड़ता है। परखने के पैमाने क्या /compact हाथ से चलाना चाहिए में समेटे गए हैं।
समेटने के वक़्त का पैमाना
अच्छा : एक काम ख़त्म होने के ठीक बाद
किसी और फ़ाइल-समूह पर जाने से पहले
बुरा : काम के बीचोंबीच (अभी काम आने वाली मान्यताएँ तक मिट जाती हैं)
"यूँ ही लंबा हो गया था इसलिए" (इसमें कोई फ़ैसला ही नहीं)
जिन तरीक़ों में खपत बेकार जाती है
ज़्यादातर खपत उन चक्करों से पैदा होती है जो किसी नतीजे तक नहीं पहुँचते। कुछ आम रूप गिनाते हैं।
टेस्ट न हों तो "हो गया" को परखा नहीं जा सकता, और फिर आप देखते हैं, टोकते हैं, दोबारा करवाते हैं ― चक्कर बढ़ते जाते हैं।
हज़ारों लाइनों में से काम की सिर्फ़ कुछ दर्जन हैं। सिर्फ़ काम का हिस्सा दे दें तो वही नतीजा सस्ते में निकल आता है।
बेमतलब के काम भी उसी इतिहास में जमा होते जाते हैं, और उसके बाद आप उन्हें हमेशा ढोते रहते हैं।
प्रोजेक्ट के अपने नियम अध्याय 6 वाली टिकाऊ मेमोरी में रख दें, तो हर बार लिखने की ज़रूरत नहीं रहती।
अपनी खपत पर नज़र रखना
घटाने से पहले यह जान लेना ज़्यादा ज़रूरी है कि अभी किस चीज़ पर कितना ख़र्च हो रहा है। अंदाज़े से बचत करेंगे तो अक्सर आप वहीं काटेंगे जहाँ काटने का कोई असर ही नहीं।
देखने की चीज़ें दो हैं। अभी की बातचीत कितनी फूल चुकी है, और कोटा कितना बचा है। पहली चीज़ समेटने का फ़ैसला करने के काम आती है, और दूसरी यह तय करने के कि "आज यह काम शुरू करना ठीक है या नहीं"।
बचा हुआ कोटा। इससे तय होता है कि भारी काम शुरू करना ठीक है या नहीं। कम बचा हो तो हल्के काम पर चले जाइए, या बहाली का इंतज़ार कीजिए।
बातचीत कितनी फूली है। इससे तय होता है कि अगले काम पर जाने से पहले समेटना है या नहीं। काम के बीचोंबीच देखने की ज़रूरत नहीं।
अहम बात यह है कि देखने की बारंबारता मत बढ़ाइए। हर कुछ मिनट में बचा हुआ कोटा देखते रहने से खपत नहीं घटती। कामों की सरहद पर देख लेना काफ़ी है।
वे बचत जो नहीं करनी चाहिए
कुछ तरीक़े ऐसे हैं जो बचत के इरादे से किए जाते हैं पर उलटा असर करते हैं। ये सब अक्सर दिख जाते हैं।
मान्यताएँ पहुँचती ही नहीं, निशाने से चूका इम्प्लीमेंटेशन बनता है और दोहराव बढ़ जाता है। काटना ही है तो समझाइश नहीं, चिपकाई जाने वाली मात्रा काटिए।
काम के बीचोंबीच समेटेंगे तो वे मान्यताएँ भी मिट जाएँगी जो अभी काम आने वाली थीं। दोबारा समझाने के हिसाब से यह महँगा पड़ता है।
जिस बग का कारण पता नहीं, उस पर उथला सोचवाएँगे तो वह ग़लत अनुमान बार-बार आज़माता रहेगा। समय भी बढ़ेगा और खपत भी।
जब सब रुका हुआ है तब छेड़ने से असर परखा ही नहीं जा सकता। बहाल होने के बाद, एक-एक करके आज़माइए।
टीम में इस्तेमाल करने पर क्या बढ़ जाता है
अकेले इस्तेमाल करते वक़्त जो खपत ध्यान में भी नहीं आती थी, वह टीम तक फैलाने पर किसी और शक्ल में सामने आ जाती है।
सबसे आम हालत यह है कि हर कोई अलग-अलग वही मान्यताएँ समझा रहा होता है। प्रोजेक्ट के नियम, नाम रखने के तरीक़े, वे जगहें जिन्हें छूना नहीं ― अगर हर कोई ये हर बार लिखता रहेगा, तो जितने लोग उतनी बार दोहराव होगा। सही जवाब है इन्हें अध्याय 6 वाली टिकाऊ मेमोरी में रखकर रिपॉज़िटरी में साझा कर देना।
दूसरा रूप यह है कि कोई एक व्यक्ति खोजबीन वाले इस्तेमाल से कोटा खपा देता है, और कोई दूसरा असली काम के बीच रुक जाता है। कोटा निजी है या संगठन का, इससे बर्ताव बदलता है, इसलिए शुरू करने से पहले कम-से-कम यह बात ज़रूर जाँच लीजिए।
नियमों से बाँधने के बजाय साझा चीज़ों को दुरुस्त करना ज़्यादा असर करता है। "टोकन बचाओ" कह देने से सबका अपना-अपना अंदाज़ा अलग-अलग हो जाता है, जबकि टिकाऊ मेमोरी और जाँच के ज़रिए रिपॉज़िटरी में मौजूद हों तो सबकी आवाजाही अपने आप घट जाती है।
व्यवहार में ― खपत घटाने की सात चालें
इन्हें असर के घटते क्रम में रखा गया है। ऊपर की दो से ही ज़्यादातर बात हल हो जाती है।
इतिहास जितना छोटा, हर चक्कर उतना सस्ता। असर सबसे ज़्यादा इसी का है।
वह ख़ुद परखकर ख़ुद सुधार सके, यह हालत बना दें तो आपके साथ की आवाजाही घट जाती है।
लक्ष्य डायरेक्टरी या फ़ाइलें बता दीजिए। खोज वाला पूरा हिस्सा ही घट जाता है।
तयशुदा कामों के लिए अधिकतम की ज़रूरत नहीं। मुश्किल जगहों पर कंजूसी मत कीजिए।
जो बात आप हर बार समझा रहे हैं, वही लिख रखने की चीज़ है (अध्याय 6)।
काम ख़त्म होने के ठीक बाद। बीच में समेटेंगे तो दोबारा समझाना पड़ेगा।
छानबीन किसी और संदर्भ में निकाल दें तो मुख्य इतिहास गंदा नहीं होता (अध्याय 6)।
कोडिंग में कुल मिलाकर लागत को अनुकूल बनाने की बात AI कोडिंग की लागत अनुकूलन की पूरी किताब में, एक चौड़े नज़रिए से समेटी गई है।
ज़रूरत से ज़्यादा बचत न करने की लकीर
आख़िर में, इस अध्याय की सबसे बड़ी बात। बचत मक़सद नहीं है।
कोटे की इतनी चिंता कि मुश्किल कामों तक को हल्की सेटिंग से चलाया जाए, और फिर निशाने से चूके इम्प्लीमेंटेशन को बार-बार सुधारा जाए ― इसमें खपत और समय, दोनों बढ़ते हैं। यह बचत के इरादे से की गई फ़िज़ूलख़र्ची का सबसे बड़ा उदाहरण है।
फ़ैसला "पीछे लौटने की मार" के आधार पर कीजिए। जिस काम में ग़लती हो जाए तो कुछ ही मिनट में लौटा जा सके, उसे हल्का और तेज़ रखिए। जिस काम में ग़लती से आधा दिन बह जाए, उसमें शुरू से ही गहरा सोचवाइए। कोटा उसी दूसरे किस्म के काम के लिए बचाकर रखने की चीज़ है।
और एक बात। रुक जाएँ तो आराम कर लेना भी संचालन का ही हिस्सा है। सीमा लग जाने पर सेटिंग उलट-पुलट करते रहने से बेहतर है कि बहाली का इंतज़ार करके पूरी तैयारी के साथ दोबारा शुरू किया जाए ― नतीजे में काम जल्दी ही ख़त्म होता है।
सारांश
- खपत पढ़ी गई फ़ाइलों, बातचीत के इतिहास और कोशिशों की गिनती से तय होती है। आपके हाथ में मुख्य रूप से इतिहास है
- "छोटा निर्देश = सस्ता" एक ग़लतफ़हमी है। सस्ता वह निर्देश है जो एक ही बार में पार हो जाए
- कोटा दो तरह का है ― छोटा चक्र और लंबा चक्र। लंबे वाले को ख़त्म कर दिया तो कई दिन हिल नहीं पाएँगे
- effort कठिनाई के हिसाब से बदलिए। हमेशा अधिकतम भी घाटे का, हमेशा न्यूनतम भी
- समेटना याद की भी बात है और साथ ही लागत की भी। लेकिन बीच में समेटेंगे तो महँगा पड़ेगा
- सबसे ज़्यादा असर दो चीज़ों का है ― बातचीत को अलग-अलग रखना और जाँच का ज़रिया पहले थमा देना
- बचत मक़सद नहीं है। फ़ैसला पीछे लौटने की मार से कीजिए, और कोटा मुश्किल जगहों के लिए बचाइए