क्लॉड कोड क्वोटा ड्रॉप: क्या एजेंट्स नए 'लीगेसी कोड माउंटेन्स' बना रहे हैं?

क्लॉड कोड के साप्ताहिक सीमा विस्तार पर ध्यान केंद्रित है, जिसमें एजेंट प्रोग्राम के टोकन उपभोग तंत्र का विश्लेषण किया गया है। लंबे समय तक चलने वाले एजेंट के कारण working set लगातार बढ़ता रहता है, प्रत्येक कदम पर इतिहास की स्थिति जमा होती रहती है, और कैश मिलने के बाद भी context में जगह घेरने की विशेषता के कारण, गणना लागत जमा होती रहती है। अत्यधिक साफ़ करने से "अर्थहीन पेज फॉल" हो सकता है, जिससे एजेंट को फिर से जानकारी प्राप्त करनी पड़ती है। लेख में इस बात पर जोर दिया गया है कि इस कोड स्थिति और डिज़ाइन स्थिति की सटीकता में असंगति के कारण AI द्वारा "परंपरागत कोड" उत्पन्न हो सकता है: भविष्य के एजेंट प्रारंभिक कोड के डिज़ाइन कारण-परिणाम को समझने में असमर्थ हो सकते हैं, जिससे अंततः queue, bypass, retry आपस में पूरक बनकर जटिल कोड बन जाता है।

लेखक, स्रोत: लेफेंगवेन

कोड वास्तव में एजेंट द्वारा लिखा गया था, लेकिन बाद के एजेंट को नहीं पता कि पिछले एजेंट ने इसे इस तरह क्यों लिखा था।

क्लॉड कोड के लिए 19 अगस्त को समाप्त होने वाला +50% साप्ताहिक कोटा बढ़ावा अब एंथ्रोपिक द्वारा 31 अगस्त तक बढ़ा दिया गया है। मूल अवधि के समाप्त होने के ठीक पहले या बाद में, हैकर न्यूज़ पर क्लॉड कोड की उपयोग लागत पर चर्चा शुरू हुई: कई लोगों ने पाया कि एजेंट कई चक्र चलाने से, भले ही कार्य अपेक्षाकृत सरल हो, कोटा तेजी से कम हो जाता है।

समस्या यह है कि Claude Code केवल अंतिम उत्पन्न कोड की कुछ पंक्तियों का ही उपयोग नहीं करता है। फाइल पढ़ना, कॉल चेन खोजना, परीक्षण चलाना, लॉग प्रोसेस करना — प्रत्येक चरण आगे के संदर्भ में जारी रहता है। जितना कार्य लंबा होगा, उतना ही Agent के पास इतिहास भारी होगा, और सिस्टम को साफ करने और संपीड़ित करने पर अधिक निर्भर होना पड़ेगा।

कोड को रिपॉजिटरी में पूरी तरह से छोड़ा जा सकता है, लेकिन प्रारंभिक डिजाइन के कारण संकुचन के साथ धीरे-धीरे पतले हो जाते हैं। इसलिए टोकन खपत और कोड स्लैश एक ही स्थान पर मिलते हैं।

सामान्य Chat coding की गणना सीमा स्पष्ट है। एक कोड अनुभाग दर्ज करें, मॉडल इसे पढ़ने के बाद व्याख्या या सुधार का प्रस्ताव देता है, और यह चक्र लगभग समाप्त हो जाता है।

और Claude Code की बेसिक यूनिट को agent loop में बदल दिया गया है। मॉडल पहले वर्तमान स्थिति को देखता है, फिर निर्णय लेता है कि अगले कदम में कौन सी फाइल पढ़ी जाए या कौन सा कमांड निष्पादित किया जाए; टूल्स द्वारा परिणाम लौटने के बाद, मॉडल अगला निर्णय लेता है।

सोर्स कोड पढ़ना, रेफरेंस खोजना, टेस्ट चलाना, Git diff देखना, फाइलें बदलना — यह लगता है जैसे एक लगातार क्रिया हो, लेकिन मॉडल की ओर से यह अलग-अलग निष्कर्ष निकालने के अनुरोधों की एक श्रृंखला है। Claude Code की आधिकारिक दस्तावेज़ इस “मॉडल निर्णय—उपकरण कॉल करना—परिणाम के आधार पर आगे निर्णय लेना” के चक्र को एजेंट के कार्य शैली की केंद्रीय बात मानती है।

जैसे कि लॉगिन स्टेटस की अनियमित रूप से असफलता की समस्या। एजेंट पहले एंट्री पॉइंट ढूंढता है, पाता है कि स्टेटस service से आ रहा है, इसलिए service को आगे पढ़ता है; कैश को देखकर यह ढूंढता है कि इसे कौन लिख रहा है; फिर टेस्ट चलाता है, टेस्ट में एक अन्य अपवाद दिखाई देता है, इसलिए fixture को देखता है; सुधार के बाद पुनः पुष्टि करता है, पुराना टेस्ट फिर से संगतता समस्या को प्रकट करता है।

शायद तब तक यह वास्तव में उन कुछ पंक्तियों कोड लिखना शुरू करता है। इसलिए,diff आकार और गणना के बीच लगभग कोई स्थिर अनुपात नहीं है। 5 पंक्तियों के पैच के पीछे केवल 3 निष्कर्ष हो सकते हैं, या 30 टूल इंटरैक्शन हो सकते हैं।

अगर एक एजेंट कार्य को विभाजित किया जाए, तो इससे दो चर प्राप्त हो सकते हैं: एक step count, जो एजेंट द्वारा कार्य पूरा करने के लिए ली गई चरणों की संख्या है; और दूसरा working set, जो वर्तमान चरण तक पहुँचने पर मॉडल को कितने प्रोजेक्ट स्टेटस को जानने की आवश्यकता है।

केवल स्टेप काउंट बढ़ाने से ही खपत बढ़ जाएगी। यदि वर्किंग सेट अभी भी सिंक्रनाइज़ हो रहा है और बढ़ रहा है, तो स्थिति पूरी तरह से अलग हो जाती है। तीसरा स्टेप शायद केवल हजारों टोकन को संसाधित करना होगा, लेकिन 30वां स्टेप पहले से ही प्रोजेक्ट नियमों, संबंधित स्रोत कोड, परीक्षण परिणामों, संशोधन इतिहास और उपकरणों के साथ-साथ निष्कर्ष निकालने के लिए भारी हो सकता है।

यही Coding Agent की लागत संरचना में परिवर्तन की शुरुआत है: गणना की मात्रा अब लिखे गए कोड की पंक्तियों पर निर्भर नहीं करती, बल्कि “कितने कदम चले × हर कदम पर कितना भार” पर निर्भर करती है।

एजेंट के एक मॉडल अनुरोध को तीन भागों में विभाजित किया जा सकता है। स्थिर भाग में सिस्टम प्रॉम्प्ट, CLAUDE.md, उपकरण परिभाषाएँ और प्रोजेक्ट नियम शामिल हैं; निरंतर बदलते भाग में कोड फाइलें, खोज परिणाम, परीक्षण लॉग, Git diff और पिछले कार्य ट्रैक शामिल हैं; और अंत में, इस चक्र में मॉडल द्वारा उत्पन्न reasoning, पाठ और कोड हैं।

यहाँ एक गलत धारणा उत्पन्न हो सकती है: जब तक पिछली सामग्री पढ़ ली गई है, तब तक दोहराए जाने पर अधिक लागत नहीं होनी चाहिए। समस्या यह है कि LLM के दो अनुरोधों के बीच कोई पारंपरिक प्रोग्राम की तरह ऐसा आंतरिक मेमोरी नहीं होता जिसे किसी भी समय एक्सेस किया जा सके। यदि अगले चरण में पिछले चरण में ज्ञात जानकारी पर निर्भरता है, तो संबंधित स्थिति को फिर से उपलब्ध context में शामिल किया जाना चाहिए।

प्रॉम्प्ट कैश इस समस्या को कम कर सकता है। क्लॉड कोड की आधिकारिक दस्तावेज़ में स्पष्ट रूप से बताया गया है कि यदि प्रॉम्प्ट कैशिंग नहीं है, तो प्रत्येक अनुरोध में पूरे इतिहास को पुनः प्रसंस्कृत करना पड़ता है; कैश हिट होने के बाद, पहले से प्रसंस्कृत स्थिर पूर्वरूप का पुनः उपयोग किया जा सकता है, जिससे दोहराए गए गणना और लागत में कमी आती है।

लेकिन कैश समाधान “क्या एक ही इतिहास को फिर से सस्ते में उपयोग किया जा सकता है” है, लेकिन “क्या इस इतिहास को अभी भी बनाए रखना चाहिए” का समाधान नहीं है। 100K Token की पुरानी स्थिति कैश में मिलने के बाद सस्ती हो जाती है, लेकिन वह अभी भी context का हिस्सा बनी रहती है और वर्तमान निष्कर्षण का आधार बनी रहती है।

इसलिए एक लंबे कार्य को लगभग इस प्रकार लिखा जा सकता है: t वें चरण का इनपुट आकार, स्थिर उपसर्ग S के बराबर होता है, जिसमें वर्तमान प्रभावी कार्य सेट W_t और इस चक्र में नवीन रूप से उत्पन्न नई जानकारी Δ_t शामिल है।

वास्तविक समस्या है W_t। यदि प्रत्येक कदम पर, एजेंट थोड़ा और स्रोत कोड पढ़ता है, थोड़ा और लॉग प्राप्त करता है, और एक निर्णय छोड़ देता है, और पुरानी जानकारी को समय पर हटाया नहीं जाता है, तो W_t कार्य के आगे बढ़ने के साथ लगातार बढ़ता रहेगा।

एक अत्यंत सरलीकृत, बिल्कुल कैश और क्लीनअप विहीन मॉडल में, यदि प्रत्येक चक्र में नए वैध स्थितियाँ लगभग समान हैं, तो कुल प्रोसेसिंग मात्रा लगभग 1 + 2 + 3 + … + n की संचयी संरचना दिखाई देगी। यानी, step count केवल दोगुना हुआ है, लेकिन पूरे कार्य द्वारा प्रोसेस किए गए इतिहास की स्थितियाँ तेजी से बढ़ सकती हैं।

वास्तविक प्रणाली में कैश, कॉन्टेक्स्ट संपादन और संपीड़न होते हैं, इसलिए यह वृद्धि वक्र का यांत्रिक रूप से पालन नहीं करती, लेकिन समस्या का आकार अपरिवर्तित रहता है: एजेंट जितना लंबा समय चलता है, प्रत्येक नया कार्रवाई उतनी ही भारी इतिहास पर आधारित होने की संभावना बढ़ जाती है।

इसलिए लंबे कार्य में वह बहुत छोटा उपयोगकर्ता प्रॉम्प्ट जल्द ही अपनी उपस्थिति खो देगा। लागत को वास्तव में नियंत्रित करने वाला, मॉडल द्वारा कार्य की निरंतरता बनाए रखने के लिए लगातार वहन किए जाने वाले कार्य सेट है।

वर्किंग सेट क्यों इतनी तेजी से फैल रहा है, टूल आउटपुट एक बड़ा स्रोत है। स्रोत कोड में कम से कम संरचना होती है, लेकिन लॉग में अक्सर ऐसा नहीं होता।

एक grep सैकड़ों संदर्भ लौटा सकता है, एक बिल्ड से बड़ी मात्रा में चेतावनियाँ निकल सकती हैं, एक टेस्ट फेल होने पर पूरा स्टैक ट्रेस साथ में आ सकता है, Docker, कंपाइलर और पैकेज मैनेजर भी कार्य के लिए दीर्घकालिक मूल्य वाले बहुत सारे टेक्स्ट उत्पन्न करते हैं।

मान लीजिए कि चरण 10 परीक्षण ने 8K टोकन लॉग उत्पन्न किया। जब यह पहली बार कॉन्टेक्स्ट में प्रवेश करता है, तो यह केवल 8K टोकन होता है। लेकिन एजेंट को स्रोत कोड की जांच करनी होगी, संशोधित करना होगा और पुनः परीक्षण करना होगा; जब तक यह लॉग वैध इतिहास में है, यह बाद की कई अनुरोधों के आधारभूत भार को बढ़ाएगा।

यह स्टोरेज सिस्टम में राइट एम्प्लिफिकेशन के समान है: एक लॉजिकल राइट, जिससे बाद में अधिक नीचले स्तर की प्रक्रियाएँ होती हैं। एजेंट में, एक टूल आउटपुट को एक्जीक्यूशन हिस्ट्री में लिखा जाता है, और फिर यह बाद के रीजनिंग के साथ आगे बढ़ता है।

इसलिए, 8K Token को टास्क के अंत से पहले की राउंड में रखना और टास्क शुरू होने के तुरंत बाद रखना, दोनों का कुल प्रभाव अलग-अलग होता है। Claude Code अब इस प्रदूषण को कम करने के लिए सक्रिय रूप से काम कर रहा है। आधिकारिक सुझाव है कि उच्च आउटपुट टास्क को sub-agent से अलग किया जाए, और स्पष्ट रूप से उल्लेख किया गया है कि सर्च परिणाम, लॉग और बड़ी मात्रा में फाइल कंटेंट मुख्य सत्र context को उपयोग करते हैं; टूल परिभाषाएँ खुद भी स्थान घेरती हैं, इसलिए टूलसेट बहुत बड़ा होना भी स्टेट बोझ में वृद्धि करता है।

लेकिन यहाँ एक विपरीत समस्या भी है: चूंकि लॉग बहुत महंगे हैं, इसलिए उन्हें पूरी तरह से काट नहीं सकते। 3000 पंक्तियों के लॉग में से केवल 20 पंक्तियाँ ही मूल कारण से संबंधित हो सकती हैं। सिस्टम पहले से नहीं जानता कि कौन सी 20 पंक्तियाँ हैं। यदि आप बहुत जल्दी साफ़ कर देते हैं, तो बाद में एजेंट को अचानक एक विवरण की आवश्यकता हो सकती है, और उसे परीक्षण को दोबारा चलाना पड़ सकता है या फ़ाइल को दोबारा खोलना पड़ सकता है।

इसे सेमेंटिक पेज फॉल्ट कहा जा सकता है। पारंपरिक वर्चुअल मेमोरी में, जब कोई प्रोग्राम एक ऐसे पेज को एक्सेस करता है जो मेमोरी में नहीं है, तो सिस्टम इसे डिस्क से पुनः लोड करता है; कोडिंग एजेंट द्वारा किसी प्रारंभिक साक्ष्य को छोड़ने के बाद भी इसी तरह की घटना होती है, केवल यह प्रकट होती है रिपॉजिटरी को पुनः खोजने, फाइलों को पुनः पढ़ने, कमांड्स को पुनः चलाने, यहां तक कि पहले ही विश्लेषित किए गए समस्या को पुनः निष्कर्षित करने के रूप में।

इसलिए लंबे कार्य एक दुविधा में फंस जाते हैं: अधिक इतिहास छोड़ने से बाद के हर कदम में भार बढ़ता जाता है; अत्यधिक आक्रामक ढंग से साफ करने से, एजेंट बार-बार पहले से देखे गए जानकारी को पुनः प्राप्त करता रहता है।

यह यह भी समझाता है कि क्यों context प्रबंधन को “कम टोकन डालने” के रूप में सरल नहीं किया जा सकता। वास्तव में हल किया जाना चाहिए working set चयन: इस क्षण किन जानकारियों को कार्यक्षेत्र में रखा जाना चाहिए और कौन सी केवल पहले ही अपना काम पूरा कर चुकी मध्यवर्ती उत्पाद हैं।

यहाँ तक कि compaction, memory और sub-agent को भी अस्तित्व का वास्तविक कारण मिल जाता है।

क्लॉड कोड संदर्भ सीमा के करीब पहुँचने पर स्वचालित रूप से सत्र को संपीड़ित कर देता है और कुछ पुराने टूल परिणामों को साफ़ भी कर देता है। आधिकारिक रूप से चेतावनी दी गई है कि लंबे सत्र में असंबंधित बातचीत, फ़ाइल सामग्री और आदेश परिणाम विंडो को भर सकते हैं और मॉडल के प्रदर्शन को प्रभावित कर सकते हैं।

सिस्टम के दृष्टिकोण से, compaction एक प्रकार का सेमेंटिक गार्बेज कलेक्शन की तरह है। समस्या यह है कि सामान्य गार्बेज कलेक्शन यह निर्धारित करता है कि "इस ऑब्जेक्ट के कोई रेफरेंस अभी भी मौजूद हैं या नहीं", जबकि Agent को यह निर्धारित करना होगा कि "इस जानकारी का भविष्य में कोई मतलब रहेगा या नहीं।"

बाद वाला बहुत कठिन है। उदाहरण के लिए, प्रारंभिक डिज़ाइन निष्कर्ष में ऐसा कहा गया था: कोई मॉड्यूल उपयोगकर्ता स्थिति को अपने आप कैश नहीं कर सकता, क्योंकि सिस्टम की आवश्यकता है कि स्थिति का केवल एक ही मालिक हो, और सभी संशोधनों को सेवा के माध्यम से ही किया जाना चाहिए।

कुछ कदमों के बाद, यदि यह सूचना इस प्रकार संक्षिप्त कर दी जाती है: "स्थिति समस्या को service के माध्यम से समायोजित करके हल किया गया था।" तो तथ्य गलत नहीं है, लेकिन सूचना बदल चुकी है। मूल सामग्री में constraint शामिल था, जबकि संक्षेप में केवल event संरक्षित है।

अगली बार एजेंट को प्रदर्शन समस्या का सामना करना पड़े, और वह देखे कि सेवा कॉल धीमी है, तो यह संभवतः मॉड्यूल में कैश जोड़ देगा। इसने अपने वर्तमान ज्ञान का उल्लंघन नहीं किया है; कैशिंग को प्रतिबंधित करने वाला कारण-परिणाम संबंध अब प्रभावी नहीं है।

Claude Code के कॉन्टेक्स्ट दस्तावेज़ में स्पष्ट रूप से बताया गया है कि कुछ path-scoped नियम और नेस्टेड CLAUDE.md फ़ाइलें सेशन के साथ compaction सारांशित हो जाती हैं, और उन्हें पुनः लोड करने के लिए मैचिंग फ़ाइल को फिर से पढ़ना आवश्यक है।

Memory लंबे समय तक ज्ञान संग्रहीत करने की समस्या को हल करने का प्रयास करता है। प्रोजेक्ट रूट डायरेक्टरी में CLAUDE.md और auto memory बिल्ड कमांड, प्रोजेक्ट स्पेसिफिकेशन, डीबगिंग अनुभव आदि को शॉर्ट-टर्म डायलॉग से निकालकर सेशन की शुरुआत में पुनः लोड कर सकते हैं। हालाँकि, Anthropic द्वारा इसकी स्थिति स्पष्ट रूप से लिखी गई है: ये memory अभी भी context हैं, और इन्हें अनिवार्य कॉन्फ़िगरेशन में शामिल नहीं किया गया है।

यह अंतर बहुत महत्वपूर्ण है। यदि "यहाँ डेटाबेस को सीधे एक्सेस नहीं किया जा सकता" केवल मेमोरी में लिखा जाता है, तो यह अभी भी एक ऐसी प्राकृतिक भाषा है जिसे मॉडल को समझना और पालन करना होगा। यदि इसी नियम को dependency lint, प्रकार सीमा या CI जाँच के रूप में लिखा जाता है, तो यह एक ऐसा सॉफ्टवेयर invariant बन जाता है जिसे आसानी से नहीं बल्कि बाईपास किया जा सकता है।

सब-एजेंट एक अलग कार्य को सुलझाता है: वर्कसेट को अलग करना। एक स्वतंत्र एजेंट को रिपॉजिटरी स्कैन करने या लंबे लॉग का विश्लेषण करने के लिए भेजें, और फिर संपीड़ित परिणाम मुख्य एजेंट को वापस भेजें, जिससे मूल शोर मुख्य थ्रेड में प्रवेश नहीं करता। Claude Code द्वारा सब-एजेंट के उपयोग के लिए आधिकारिक उद्देश्यों में से एक context isolation है।

इसकी कीमत भी दिलचस्प है: मुख्य एजेंट को अधिक साफ स्थिति मिली, लेकिन कुछ मूल साक्ष्य खो दिए; कई एजेंट एक साथ चलने पर, अपने-अपने कॉन्टेक्स्ट बनाते हैं। इसलिए compaction, memory, sub-agent को एक साथ देखने पर, वास्तव में यह एजेंट युग की एक मेमोरी हार्डवेयर व्यवस्था की तरह लगता है:

वर्तमान context महंगी कार्य स्मृति है, compaction संपीड़न के लिए जिम्मेदार है, memory सेशन के बीच स्थिति को संग्रहीत करता है, और sub-agent शोर को स्वतंत्र पता अंतरिक्ष से अलग करता है। समस्या अब "context पर्याप्त बड़ा है या नहीं" से एक अन्य स्तर पर बदल गई है:

किन स्थितियों को उच्च गुणवत्ता वाले रूप में सहेजने की आवश्यकता है और किन स्थितियों के केवल सारांश को बरकरार रखने की आवश्यकता है। यह प्रश्न बाद के कोड की गुणवत्ता पर सीधा प्रभाव डालेगा।

पिछली निष्पादन संरचना को समझने के बाद, क्लॉड कोड की साप्ताहिक सीमा को देखें, तो आप देखेंगे कि प्लेटफॉर्म के लिए "संदेश संख्या" के आधार पर एजेंट को मापना मुश्किल हो जाता है, क्योंकि एक संदेश का स्थिर अर्थ खो चुका है।

एक चर का नाम बदलना एक संदेश है, जबकि पूरे प्रमाणीकरण मॉड्यूल को पुनर्गठित करना भी एक संदेश है। पहला कुछ कदमों में समाप्त हो सकता है, जबकि दूसरा कई दर्जन चक्र चल सकता है, कई दर्जन फाइलों को पढ़ सकता है और कई Agent को शुरू कर सकता है। एक ही अनुरोध, जिसकी पीछे की संसाधन आवश्यकताएँ पूरी तरह से अलग माप की हो सकती हैं।

Claude Code ने स्क्रॉलिंग सीमा और साप्ताहिक कोटा के साथ इसे पैकेज किया है; Codex अब input token, cached input token और output token के आधार पर credits की गणना करता है; Cursor के प्लान Agent को विभिन्न usage pool प्रदान करते हैं, और तीसरे पक्ष के मॉडल की खपत मॉडल API मूल्य पर निर्भर करेगी।

तीनों उत्पादों की इंटरफेस भाषाएँ अलग-अलग हैं, लेकिन नीचे की समस्याएँ बहुत समान हैं: एक ऐसे बुद्धिमान कार्यक्रम को तर्क संसाधन कैसे आवंटित किया जाए जिसका निष्पादन मार्ग पहले से अज्ञात हो। एक Coding Agent कितने समय तक चलेगा, यह कार्य शुरू होने पर कठिनाई से निर्धारित किया जा सकता है।

मॉडल जल्दी ही मूल कारण ढूंढ सकता है, या कई गलत अनुमान लगा सकता है; एक ही परीक्षण में सफल हो सकता है, या लंबे समय तक डीबग लूप में फंस सकता है; एक Agent की आवश्यकता हो सकती है, या कई sub-agent में विभाजित किया जा सकता है।

पारंपरिक API एक request के आधार पर शुल्क लेना पसंद करते हैं, क्योंकि एक request के संसाधनों में उतार-चढ़ाव को एक निश्चित सीमा में रखा जा सकता है। Agent इस स्थिरता को बिखेर देता है। इसलिए यहाँ Token थोड़ा CPU time की तरह महसूस होने लगता है।

इस तुलना को बराबर नहीं माना जा सकता। विभिन्न मॉडल एक ही संख्या में टोकन को संसाधित करने के लिए अलग-अलग कैलकुलेशन लागत का उपयोग करते हैं, और input, cached input और output की अलग-अलग लागत होती है। लेकिन डेवलपर के पक्ष से, उनका कार्य लगातार समान होता जा रहा है: ये सभी एक कार्य को आगे बढ़ाने के लिए कितने कैलकुलेशन संसाधनों का उपयोग हुआ, इसका वर्णन करते हैं।

एंथ्रोपिक ने इस साल क्लॉड कोड के उपयोग सीमा में वृद्धि करते समय, सीधे ही क्वोटा बढ़ाने और नए कंप्यूट क्षमता को जोड़ दिया। इससे एक दिलचस्प सूचक में परिवर्तन आएगा। पहले कोडिंग एजेंट की तुलना करते समय, आसानी से यह देखा जाता था कि "एक ही प्रश्न को कौन एक बार में बेहतर ढंग से लिखता है।" अब संभवतः अधिक महत्वपूर्ण होगा: समान इंजीनियरिंग स्थिति परिवर्तन पूरा करने में, कौन कम प्रभावी कंप्यूटेशन का उपयोग करता है।

अगर एक एजेंट बहुत सारे टोकन खर्च करता है, केवल फाइलें खोलने, परीक्षण दोबारा चलाने और खोए हुए कॉन्टेक्स्ट को दोबारा बहाल करने के लिए, तो उन टोकन्स ने संबंधित स्तर की इंजीनियरिंग प्रगति के लिए कोई लाभ नहीं दिया।

और यह अक्षम स्थिति पुनर्स्थापन, ठीक उसी स्तर पर तकनीकी ऋण से मिलती है।

यहाँ एक Coding Agent द्वारा रखरखाव किया जा रहा सॉफ्टवेयर दो समानांतर रूप से विकसित हो रही स्थितियों में अमूर्त किया जा सकता है। एक स्थिति कोड स्थिति R_t है। फाइलें, प्रकार, इंटरफेस, परीक्षण, Git commit इन सभी को इस स्तर में शामिल किया जाता है। Agent के 20वें चरण में जोड़ी गई एक पंक्ति retry, जब तक इसे हटाया नहीं जाता, 100वें चरण में फाइल खोलने पर भी पूरी तरह मौजूद रहती है। कोड पिछले संशोधनों को बहुत उच्च सटीकता के साथ संग्रहीत करता है।

दूसरा सेट डिज़ाइन स्थिति है M_t। यहाँ retry क्यों आवश्यक है, क्यों वह कैश केवल सेवा में रखा जा सकता है, क्यों इस स्थिति के दो मालिक नहीं हो सकते, क्यों एक ऐसा अतिरिक्त जांच अभी नहीं हटाया जा सकता, ये सभी जानकारी डिज़ाइन कारण-परिणाम से संबंधित हैं।

M_tइसमें गिट की तरह कोई प्राकृतिक नुकसानरहित स्टोरेज नहीं है। यह संवाद, तर्क, उपकरण लौटाव, मेमोरी, नियम फ़ाइलों और संपीड़न सारांश में बिखरा हुआ है। कार्य आगे बढ़ने के साथ, कुछ भागों को साफ़ कर दिया जाता है, कुछ को सारांशित कर दिया जाता है, और कुछ को पुनः प्राप्त करने की आवश्यकता होती है।

इससे एक महत्वपूर्ण असमानता उत्पन्न होती है: परिणाम उच्च गुणवत्ता के साथ संचित हो सकते हैं, लेकिन इन परिणामों को उत्पन्न करने वाले कारण-प्रभाव संबंध लगातार नमूनाकरण कम होते जाते हैं। यह केवल “एजेंट चीजें भूल जाता है” कहने से कहीं अधिक गंभीर है।

एक समानांतर समस्या के दौरान, एजेंट ने विश्लेषण के बाद एक कतार में जोड़ दिया। उस समय उसके पास पूर्ण निष्कर्ष था: केवल लिखने का पथ A में प्रतिस्पर्धा थी, इसलिए कतार केवल A को ही कवर कर सकती थी; लिखने का पथ B को निम्न लेटेंसी की आवश्यकता थी, इसलिए इसे इस कतार में नहीं डाला जा सकता था।

कोड ने queue को पूरी तरह से सहेज लिया है। लंबे समय तक निष्पादित होने के बाद, डिज़ाइन स्थिति केवल “यहाँ race condition को हल करने के लिए queue का उपयोग किया जाता है” बच जाती है।

बाद में B में भी एक अनियमित त्रुटि आई। एजेंट ने फिर से कोड पढ़ते समय, B को स्वाभाविक रूप से मौजूदा कतार में जोड़ दिया।

फिर देरी बढ़ी, इसलिए बाइपास जोड़ा गया। बाइपास ने अनियमित स्थिति असंगति को उत्पन्न किया, इसलिए बाहरी ढांचे में पुनः प्रयास जोड़ा गया। यहाँ तक कि कोई भी संशोधन अव्यवस्थित नहीं लगता। प्रत्येक पैच उस समय के स्थानीय स्थिति को देखते हुए बहुत तर्कसंगत लग सकता है। लेकिन कोड पहले से “एक स्पष्ट समानांतर मॉडल” से बदलकर queue, bypass और retry के परस्पर पूरक रूप में हो चुका है।

AI कोड का स्लैश शायद इसी तरह बन गया। यह अचानक मॉडल द्वारा एक गंदगी लिखे जाने के रूप में नहीं दिख सकता, बल्कि स्थानीय रूप से सही बातों के क्रमिक जमावट के रूप में दिख सकता है, जिससे समग्र मॉडल धीरे-धीरे गायब हो जाता है।

इस तरह की समस्याएँ पारंपरिक सॉफ्टवेयर में आमतौर पर कर्मचारियों के हस्तांतरण के माध्यम से धीरे-धीरे बन जाती हैं। मूल लेखक चले जाते हैं, नए डेवलपर्स पुराने कोड को देखते हैं, लेकिन नहीं जानते कि यह क्यों मौजूद है, इसलिए वे इसके बाहर एक अनुकूलता तर्क का एक और परत जोड़ देते हैं।

कोडिंग एजेंट ने "कर्मचारी हस्तांतरण" को "संदर्भ हस्तांतरण" में बदल दिया। 20वें और 100वें कदम अभी भी एक ही Claude Code सेशन लगते हैं, लेकिन उन्हें प्राप्त डिज़ाइन स्थिति पूरी तरह से समान नहीं है। सूचना के दृष्टिकोण से, यह दो इंजीनियरों की तरह है जो एक समान रिपॉजिटरी को एक ऐसे हस्तांतरण दस्तावेज़ के माध्यम से बनाए रखते हैं, जो लगातार कम होता जा रहा है।

परीक्षण केवल कुछ हिस्से ही सुलझा सकते हैं। परीक्षण व्यवहार की सुरक्षा में कुशल हैं: इंटरफ़ेस को क्या लौटाना चाहिए, किसी इनपुट से सिस्टम नहीं टूटना चाहिए, पिछली बग्स वापस नहीं आनी चाहिए। लेकिन कई आर्किटेक्चरल प्रतिबंध स्वाभाविक रूप से इनपुट-आउटपुट के रूप में प्रकट नहीं होते।

स्थिति केवल एक मालिक हो सकती है, डोमेन स्तर UI पर प्रतिलोम निर्भरता नहीं रख सकता, किसी पैकेज को सीधे डेटाबेस से जोड़ने की अनुमति नहीं है, लिखने की क्रियाएँ एक समान ट्रांजैक्शन सीमा से होनी चाहिए, ये प्रतिबंध अगर केवल दस्तावेज़ या एजेंट की स्मृति में मौजूद हैं, तो स्थानीय ठीक करने में आसानी से उल्लंघित हो सकते हैं।

एक बहुत ही परेशानी भरी इंजीनियरिंग स्थिति उत्पन्न होती है: टेस्ट अभी भी हरा है, लेकिन कोड अब समझाने में बहुत कठिन हो रहा है। इससे अधिक खतरनाक बात यह है कि इसमें प्रतिक्रिया चक्र मौजूद हैं।

आर्किटेक्चर अव्यवस्थित होने लगता है, अगली बार एजेंट को फ़ंक्शन समझने के लिए अधिक फ़ाइलें पढ़नी पड़ती हैं; निर्भरताएँ जितनी अधिक जटिल होती हैं, वर्किंग सेट उतना ही बड़ा होता है; वर्किंग सेट जितना भारी होता है, सिस्टम को उतना ही अधिक साफ़ करने और संपीड़ित करने की आवश्यकता होती है; डिज़ाइन कारण-परिणाम को जितना पतला रखा जाता है, बाद में संशोधन उतने ही अधिक वर्तमान कोड और स्थानीय परीक्षण पर निर्भर होते हैं।

इसलिए कोड की जटिलता बढ़ने लगती है, जिससे टोकन लागत बढ़ती है, और टोकन का दबाव वापस छोटे स्टेट्स के रखने और स्थानीय ठीक करने को प्रोत्साहित करता है। यही Agent coding में “जितना इटरेट करते हैं, उतनी समस्याएँ बढ़ती हैं” के पीछे का अधिक चिंताजनक तंत्र है।

यह एक अलग मॉडल क्षमता की समस्या नहीं है, बल्कि एक सिस्टम समस्या है जिसमें कोड स्टेट और डिज़ाइन स्टेट की सटीकता असंगत है।

कोडिंग एजेंट अब लंबे समय तक काम करने में सक्षम होता जा रहा है, लेकिन "कुछ घंटों तक चलना" खुद एक अच्छा क्षमता सूचक नहीं हो सकता।

अगर एक एजेंट 3 घंटे काम करने के बाद, अपने 2 घंटे पहले संशोधित फ़ाइल को फिर से पढ़ना चाहता है, किसी अमूर्त के अस्तित्व को फिर से तर्कसंगत ढंग से समझना चाहता है, और पहले से चलाए गए परीक्षण को फिर से चलाना चाहता है, तो इन 3 घंटों में काफी हद तक कैलकुलेशन स्टेट रिकवरी पर खर्च हो रहा है।

अगला प्रश्न यह बन जाएगा: एक एजेंट 50 स्टेप्स, 100 स्टेप्स के बाद भी अपने भविष्य के निर्णयों के लिए कितनी कारण-परिणाम सूचना बरकरार रख सकता है।

इसे स्टेटस फिडेलिटी कहा जा सकता है।

क्योंकि यह नहीं मापता कि context में कितने Token फिट हो सकते हैं, बल्कि यह मापता है कि टूल कॉल, संपीड़न, क्रॉस-सेशन और मेमोरी रिट्रीवल के बाद कितनी कुंजी डिज़ाइन जानकारी उपयोगयोग्य रूप में बनी रहती है। इसका अर्थ यह भी है कि Agent की लंबी अवधि की स्मृति केवल लंबे context पर निर्भर नहीं हो सकती।

कुछ ज्ञान को मेमोरी में रखना उपयुक्त है, जैसे प्रोजेक्ट बिल्डिंग तरीके और डेवलपमेंट आदतें; कुछ निर्णय संरचित ADR या कोड इंडेक्स में जाने चाहिए; और जो नियम एक बार उल्लंघित होने पर सिस्टम की आर्किटेक्चरल बाउंड्रीज़ को नुकसान पहुंचा सकते हैं, उन्हें सीधे टाइप, टेस्ट, lint, डिपेंडेंसी नियमों और CI में लिखा जाना चाहिए।

जब एक नियम सॉफ्टवेयर द्वारा लागू अनुशासन में बदल जाता है, तो एजेंट को उसे "याद" रखने की आवश्यकता नहीं होती। अगले चरण में एजेंट एक संवाद को भूल सकता है, लेकिन कंपाइलर और परीक्षण को आसानी से नहीं पार कर सकता।

अगर फिडेलिटी कम है, तो एजेंट जितना लंबा समय चलेगा, वह तन्त्र में उतने ही अधिक बम छोड़ रहा होगा।

यह भी संभवतः Coding Agent के लिए एक सीमा है जिसे पार करना आवश्यक है: “कोड लिखने में सक्षम” से “सॉफ्टवेयर को लंबे समय तक बनाए रखने में सक्षम” बनने के लिए, डिज़ाइन ज्ञान को संभावनाओं वाली भाषा की याददाश्त से, एक ऐसी सॉफ्टवेयर स्थिति में स्थानांतरित करना जिसे खोजा जा सके, सत्यापित किया जा सके और निष्पादित किया जा सके।

अन्यथा, जितना लंबा स्वतंत्र रूप से समय चलेगा, उतना ही अवास्तविक परिदृश्य उत्पन्न होगा। एजेंट कोड लिखने की गति तेज होती जा रही है, प्रोजेक्ट भी तेजी से बदल रहा है, लेकिन कुछ समय बाद, इसे पिछले समय के दौरान छोड़े गए दुनिया को फिर से समझना पड़ता है।

पारंपरिक पुराने कोड में एक आम वाक्य है: "इस भाग को मत छूओ, यह क्यों फट रहा है यह पता नहीं।"

AI का पुराना कोड और भी अजीब हो सकता है: कोड वास्तव में Agent द्वारा लिखा गया है, केवल बाद के Agent को पहले के Agent ने इसे इस तरह क्यों लिखा था, यह नहीं पता है।