Red Hat च्या २१९ वास्तविक-जगातील (real-world) सत्रांच्या विश्लेषणांनुसार, Claude Code त्याच्या टोकन बजेटचा तीन चतुर्थांश भाग केवळ कोडबेस वाचण्यात खर्च करतो. हे निष्कर्ष AI-आधारित कोडिंग एजंट्स कोड तयार करण्यात वेळ वाया घालवतात या सामान्य समजुतीला छेद देतात आणि असे सुचवतात की डेव्हलपर्सनी केवळ मॉडेलच्या वेगावर लक्ष केंद्रित न करता 'कॉन्टेक्स्ट-मॅनेजमेंट' (context-management) समस्येवर उपाय शोधले पाहिजेत.

या दाव्यामागील डेटा

Red Hat ने Anthropic च्या Claude Code सोबतच्या २१९ संवादांचे परीक्षण केले आणि प्रत्येक टर्नसाठी (turn) वापरल्या जाणाऱ्या टोकन्सची गणना केली. या नमुन्यात, मध्यवर्ती टर्नमध्ये ७५% टोकन्स सभोवतालचा कोड आणि डॉक्युमेंटेशन समजून घेण्यासाठी (ingesting) वापरले गेले, तर केवळ २५% टोकन्स नवीन ओळी तयार करण्यासाठी वापरले गेले. बहुतेक AI प्रदाते इनपुट आणि आउटपुट टोकन्ससाठी समान दर आकारत असल्याने, व्यवहाराचा "वाचण्याचा" (reading) भाग खर्चाचा मोठा हिस्सा व्यापतो.

वाचण्याचा खर्च का महत्त्वाचा आहे

ऑप्टिमायझेशन स्ट्रॅटेजी (Optimization strategy)

अनेक टीम्स वेगाच्या वाढीमुळे प्रत्येक जनरेशनमध्ये काही सेकंद वाचतील या आशेने अधिक वेगवान किंवा मोठ्या मॉडेल्सवर संसाधने खर्च करतात. जर तीन चतुर्थांश काम केवळ कॉन्टेक्स्ट मिळवणे असेल, तर वेगवान मॉडेलमुळे एकूण वेळेत केवळ अत्यल्प बचत होते. खरा महत्त्वाचा घटक म्हणजे प्रत्येक टर्नमध्ये मॉडेलला किती कॉन्टेक्स्ट प्रोसेस करावा लागतो.

खर्च नियंत्रण (Cost control)

जेव्हा एखादा AI असिस्टंट प्रत्येक विनंतीवर (request) त्याच रिपॉझिटरीची स्थिती पुन्हा वाचतो, तेव्हा इनपुट टोकन्स मोठ्या प्रमाणात वाढतात. मोठ्या कॉन्टेक्स्ट विंडो असलेल्या प्रकल्पांमध्ये, तयार केलेला कोड कमी असला तरीही त्यांचे बिल मोठ्या प्रमाणात वाढू शकते.

इंजिनिअरिंग फोकस (Engineering focus)

टूल बिल्डर्स अनेकदा प्रॉम्प्ट्स (prompts) कसे तयार केले जातात याकडे दुर्लक्ष करून उच्च मॉडेल गुणवत्तेच्या मागे धावतात. हे विश्लेषण सुचवते की "कॉन्टेक्स्ट इंजिनिअरिंग" (context engineering) – म्हणजेच मॉडेलला दिला जाणारा कोड कमी करणे (trimming), कॅशिंग (caching) आणि सारांशित करणे (summarizing) – हे मॉडेलच्या टप्प्याटप्प्याने केलेल्या अपग्रेड्सपेक्षा जास्त ROI देते.

वाचण्याचा अतिरिक्त भार (reading overhead) कमी करण्यासाठी व्यावहारिक पावले

  • अनावश्यक फाइल्स काढून टाका (Prune irrelevant files) – सध्याच्या कामासाठी आवश्यक नसलेल्या फाइल्स प्रॉम्प्टमधून काढून टाका. लहान प्रॉम्प्ट्स म्हणजे कमी इनपुट टोकन्स.
  • वारंवार वाचलेले डेटा कॅश करा (Cache repeated reads) – कोडबेसच्या स्थिर भागांचे मॉडेलने केलेले विश्लेषण साठवून ठेवा आणि प्रत्येक वेळी तोच मजकूर पुन्हा पाठवण्याऐवजी त्याचा विविध टर्न्समध्ये पुनर्वापर करा.
  • टूल आउटपुट्स कॉम्प्रेस करा (Compress tool outputs) – जेव्हा बाह्य टूल्स मोठ्या प्रमाणात डेटा (उदा. lint reports) परत करतात, तेव्हा ते Claude ला देण्यापूर्वी त्यांचा सारांश तयार करा.
  • इन्क्रिमेंटल डिफ्स (incremental diffs) वापरा – संपूर्ण फाईलचा मजकूर पाठवण्याऐवजी केवळ मागील टर्नपासून झालेल्या बदलांनाच पाठवा.

या डावपेचांचा उद्देश AI ला प्रत्येक संवादावर त्याच रिपॉझिटरीचा स्नॅपशॉट पुन्हा वाचण्यापासून रोखणे हा आहे, ज्यामुळे लॅटन्सी (latency) आणि खर्च दोन्ही कमी होतात.

प्रतिवाद: वेग अजूनही महत्त्वाचा आहे

काही डेव्हलपर्स असा युक्तिवाद करतात की वेगवान मॉडेल अजूनही महत्त्वाचे आहे कारण ते तयार होणाऱ्या २५% टोकन्सची लॅटन्सी कमी करते. लॅटन्सी-संवेदनशील वातावरणात—जसे की IDE प्लगइन्स ज्यांना त्वरित प्रतिसाद द्यावा लागतो—प्रत्येक मिलिसेकंद महत्त्वाचा असतो. वाचण्यावर आधारित हे प्रोफाइल वेगवान मॉडेलचा फायदा संपवत नाही; ते केवळ त्याचा सापेक्ष प्रभाव कमी करते.

पुढे काय पाहावे

Red Hat चा अभ्यास मर्यादित सत्रांवर आधारित आहे, त्यामुळे व्यापक नमुन्यांमुळे इतर भाषा किंवा प्रकल्पांच्या आकारासाठी वेगळे टोकन वितरण दिसून येऊ शकते. जर भविष्यातील डेटा ७५% वाचण्याचे प्रमाण सिद्ध करत असेल, तर आपण कॉन्टेक्स्ट आपोआप कमी करणारे आणि कॅश करणारे टूल्स, किंवा जलद कॉन्टेक्स्ट इनजेशनसाठी (context ingestion) तयार केलेली मॉडेल आर्किटेक्चर पाहू शकतो.

थोडक्यात महत्त्वाचे (Takeaway): AI-सहाय्यित कोडिंगसाठी, मॉडेलला अधिक वेगाने लिहिण्यास सांगण्यापेक्षा त्याला कमी माहिती देणे हा कामगिरी सुधारण्याचा सर्वात स्वस्त मार्ग आहे. Red Hat चे आकडे एक स्पष्ट मुद्दा मांडतात: तुमचे प्रॉम्प्ट्स कमी करा (trim), कॅश करा आणि सारांशित करा, आणि तुम्हाला वेळ आणि पैसा या दोन्हीमध्ये प्रत्यक्ष बचत दिसून येईल.