Red Hat के 219 वास्तविक सत्रों (real-world sessions) के विश्लेषण के अनुसार, Claude Code अपने टोकन बजट का तीन-चौथाई हिस्सा केवल कोडबेस को पढ़ने में खर्च करता है। यह निष्कर्ष इस सामान्य धारणा को उलट देता है कि AI-संचालित कोडिंग एजेंट कोड जनरेट करने में समय बर्बाद करते हैं, और यह सुझाव देता है कि डेवलपर्स को केवल मॉडल की गति पर नहीं, बल्कि कॉन्टेक्स्ट-मैनेजमेंट (context-management) की समस्या पर ध्यान देना चाहिए।

दावे के पीछे का डेटा

Red Hat ने Anthropic के Claude Code के साथ 219 इंटरैक्शन का परीक्षण किया और प्रति टर्न टोकन उपयोग की गणना की। नमूने में, औसत टर्न ने आसपास के कोड और दस्तावेज़ों को पढ़ने (ingesting) में 75% टोकन आवंटित किए, जबकि केवल 25% नए कोड लिखने में गए। चूंकि अधिकांश AI प्रदाता इनपुट और आउटपुट टोकन के लिए समान दर से शुल्क लेते हैं, इसलिए लेनदेन का "पढ़ने" वाला हिस्सा लागत का बड़ा हिस्सा बनता है।

पढ़ने की लागत क्यों मायने रखती है

ऑप्टिमाइज़ेशन रणनीति

कई टीमें तेज़ या बड़े मॉडलों में संसाधन लगाती हैं, इस उम्मीद में कि गति में वृद्धि से प्रत्येक जनरेशन के समय में कुछ सेकंड की कमी आएगी। यदि तीन-चौथाई काम केवल कॉन्टेक्स्ट को शामिल करना है, तो एक तेज़ मॉडल कुल समय का केवल एक छोटा हिस्सा ही बचाता है। असली कुंजी यह है कि मॉडल को प्रत्येक टर्न में कितने कॉन्टेक्स्ट को प्रोसेस करना पड़ता है।

लागत नियंत्रण

जब एक AI असिस्टेंट हर अनुरोध पर उसी रिपॉजिटरी स्टेट को दोबारा पढ़ता है, तो इनपुट टोकन तेजी से बढ़ते हैं। बड़े कॉन्टेक्स्ट विंडो वाले प्रोजेक्ट्स में बिल नाटकीय रूप से बढ़ सकते हैं, भले ही जनरेट किए गए कोड की मात्रा कम ही क्यों न हो।

इंजीनियरिंग फोकस

टूल बनाने वाले अक्सर प्रॉम्प्ट कैसे बनाए जाते हैं, इस पर ध्यान दिए बिना उच्च मॉडल गुणवत्ता के पीछे भागते हैं। विश्लेषण बताता है कि "कॉन्टेक्स्ट इंजीनियरिंग" (context engineering) – यानी मॉडल को दिए जाने वाले कोड को ट्रिम करना, कैश करना और सारांशित करना – मॉडल के क्रमिक अपग्रेड की तुलना में अधिक ROI देता है।

रीडिंग ओवरहेड को कम करने के व्यावहारिक कदम

  • अप्रासंगिक फ़ाइलों को हटाएँ (Prune) – प्रॉम्प्ट से उन फ़ाइलों को हटा दें जिनकी वर्तमान कार्य में आवश्यकता नहीं है। छोटे प्रॉम्प्ट का मतलब है कम इनपुट टोकन।
  • बार-बार होने वाली रीडिंग को कैश करें – कोडबेस के स्थिर हिस्सों के मॉडल द्वारा किए गए इंटरप्रिटेशन को स्टोर करें और हर बार वही टेक्स्ट भेजने के बजाय उसे विभिन्न टर्न्स में पुन: उपयोग करें।
  • टूल आउटपुट को कंप्रेस करें – जब बाहरी टूल बड़े डेटा (जैसे lint रिपोर्ट्स) लौटाते हैं, तो उन्हें वापस Claude को भेजने से पहले सारांशित (summarize) करें।
  • इंक्रीमेंटल डिफ (incremental diffs) का उपयोग करें – पूरी फ़ाइल की सामग्री भेजने के बजाय केवल पिछले टर्न के बाद हुए बदलावों को भेजें।

इन रणनीतियों का उद्देश्य AI को हर इंटरैक्शन पर उसी रिपॉजिटरी स्नैपशॉट को दोबारा पढ़ने से रोकना है, जिससे लेटेंसी और लागत दोनों कम हो सकें।

प्रति-तर्क: गति अभी भी मायने रखती है

कुछ डेवलपर्स का तर्क है कि एक तेज़ मॉडल अभी भी महत्वपूर्ण है क्योंकि यह उन 25% टोकन की लेटेंसी को कम करता है जो जनरेट किए जाते हैं। लेटेंसी-संवेदनशील वातावरण में—जैसे IDE प्लगइन्स जिन्हें तुरंत प्रतिक्रिया देनी होती है—हर मिलीसेकंड मायने रखता है। रीडिंग-प्रधान प्रोफाइल तेज़ मॉडल के लाभ को खत्म नहीं करता है; यह केवल इसके सापेक्ष प्रभाव को कम कर देता है।

आगे क्या देखें

Red Hat का अध्ययन सत्रों के एक सीमित सेट पर आधारित है, इसलिए व्यापक सैंपलिंग अन्य भाषाओं या प्रोजेक्ट के आकार के लिए अलग टोकन वितरण प्रकट कर सकती है। यदि भविष्य का डेटा 75% रीडिंग के आंकड़े की पुष्टि करता है, तो हम ऐसे टूलिंग की ओर बदलाव देख सकते हैं जो स्वचालित रूप से कॉन्टेक्स्ट को ट्रिम और कैश करता है, या यहाँ तक कि तेज़ कॉन्टेक्स्ट इनजेशन (ingestion) के लिए ट्यून किए गए मॉडल आर्किटेक्चर भी देख सकते हैं।

मुख्य बात (Takeaway): AI-असिस्टेड कोडिंग के लिए, प्रदर्शन में सबसे सस्ता सुधार मॉडल को कम डेटा देने से आता है, न कि उसे तेज़ लिखने के लिए मजबूर करने से। Red Hat के आंकड़े एक स्पष्ट मामला पेश करते हैं: अपने प्रॉम्प्ट को ट्रिम, कैश और सारांशित करें, और आप समय और पैसा दोनों में वास्तविक बचत देखेंगे।