एंथ्रोपिक के क्लॉड मॉडल को कोड जनरेशन और एजेंट विश्वसनीयता में तकनीकी चुनौतियों का सामना करना पड़ रहा है

एंथ्रोपिक को हाल ही में क्लॉड मॉडल के कई तकनीकी चुनौतियों का सामना करना पड़ा है। कोड जेनरेशन में वॉटरमार्क एम्बेडिंग के प्रतिबंधों के कारण स्वतंत्रता कम हो गई है; सोनेट 5 का एडेप्टिव थिंकिंग मैकेनिज्म एक ही मॉडल को विभिन्न कंप्यूटेशनल इनपुट के साथ समायोजित करने की अनुमति देता है, जिससे उत्पाद लाइन क्षमता की सीमाएँ धुंधली हो गई हैं; 1M कॉन्टेक्स्ट दिखने में पर्याप्त लगता है, लेकिन लंबे एजेंट संवाद में मॉडल वास्तव में केवल लगभग 20%-30% ही प्रभावी ढंग से उपयोग कर पाता है, और उसके बाद स्थिति भ्रम और लापता होने की समस्या उत्पन्न होती है; कॉन्टेक्स्ट संपीड़न के दौरान यह पहचानना मुश्किल होता है कि कौन सी जानकारी अभी भी मान्य है, अस्थायी मान्यताओं को गलती से तथ्य में बदल दिया जा सकता है; एजेंट द्वारा परिवेश में सक्रिय परिवर्तन के बाद, मॉडल अब मूल समस्या के बजाय अपने द्वारा बनाए गए नए त्रुटियों का विश्लेषण करने लगता है। लेख में बताया गया है कि लंबे एजेंट की विश्वसनीयता अब केवल मॉडल के एकल-चरण प्रदर्शन पर निर्भर नहीं है, बल्कि स्थिति स्पष्टता, क्रियाओं की सत्यापनयोग्यता, और त्रुटियों को पलटने की क्षमता पर निर्भर करती है।

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

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

Anthropic ने हाल ही में थोड़ा ऐसा ही महसूस किया है।

इन दिनों X पर एक पोस्ट ने क्लॉड के इस समय के कुछ आम असंतोष को एक साथ रखा है: टेक्स्ट और कोड में मशीन-पठनीय टैग शामिल किए जा रहे हैं, सोनेट 5 का वास्तविक अनुभव मॉडल अपग्रेड के शोर के साथ नहीं बढ़ पा रहा है, फेबल 5 की कीमत अधिक है, लेकिन इसे ऑपस 5 से कहीं बेहतर महसूस करना मुश्किल है; और एक और अधिक चोट पहुंचाने वाली प्रतिक्रिया यह है कि फेबल 5 का संदर्भ केवल लगभग 20%–30% तक ही उपयोग होता है, और उसके बाद क्षमता गिरने लगती है।

ये चीजें सतही रूप से कोई संबंध नहीं रखतीं, एक जैसे जनरेशन मैकेनिज्म की समस्या, एक जैसे मॉडल क्षमता की समस्या, एक जैसे मूल्य निर्धारण की समस्या, और एक तो लंबे कॉन्टेक्स्ट में खराबी की तरह है।

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

इसलिए Anthropic की हालिया समस्याएँ, सिर्फ इतनी सरल नहीं हैं कि “मॉडल कमजोर हो गया है”। बल्कि ऐसा लगता है कि Claude जितना मजबूत होता जा रहा है, उतना ही जनरेशन, कैलकुलेशन, कॉन्टेक्स्ट और एजेंट रनटाइम के बीच आपस में एक-दूसरे को पीछे खींचने लगे हैं।

01

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

पेपर: https://arxiv.org/pdf/2301.10226

प्राकृतिक भाषा में अक्सर कई अर्थरूपी उम्मीदवार होते हैं। एक ही अर्थ को शब्द बदलकर या वाक्यांश क्रम बदलकर व्यक्त किया जा सकता है, और मॉडल कई स्थितियों में कुछ उत्पादन अतिरिक्तता रखता है। टेक्स्ट वॉटरमार्किंग की एक सामान्य दृष्टिकोण यह है कि इस अतिरिक्तता का उपयोग करके, कई स्वीकार्य टोकन के बीच नमूना प्रायिकता में हल्का परिवर्तन किया जाए, और पर्याप्त लंबे समय तक सं tích करने पर सांख्यिकीय पैटर्न छोड़ दिए जाएं।

कोड में बहुत सारी निम्न एंट्रॉपी स्थितियाँ हैं। चर घोषणा के बाद, बाद के संदर्भों में लगभग हमेशा एक ही नाम का उपयोग किया जाता है; JSON के क्षेत्र, उद्धरण चिह्न और कोष्ठक कठोर संरचनात्मक प्रतिबंधों के अधीन होते हैं; फ़ंक्शन पैरामीटर इंटरफ़ेस के अनुसार होने चाहिए; पथ, नियमित अभिव्यक्ति, SQL, Shell कमांड में, एक टोकन में परिवर्तन सीधे व्यवहार को बदल सकता है।

प्रायिकता वितरण के अनुसार, ये स्थितियाँ अक्सर बहुत तीव्र होती हैं। सही टोकन उच्च प्रायिकता लेता है, जबकि अन्य उम्मीदवार केवल एक अलग अभिव्यक्ति नहीं, बल्कि संभवतः गलत हो सकते हैं। इसलिए, कोड जलनख़ाल के सामने मूल सीमा वास्तव में कोडिंग क्षमता है।

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

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

Anthropic ने Claude टेक्स्ट टोकन के बारे में यह नहीं बताया है कि नमूनाकरण कैसे बदलता है, इसलिए Claude Code की गुणवत्ता में परिवर्तन को सीधे किसी एक जलचिह्न एल्गोरिथम पर नहीं डाला जा सकता।

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

02

Sonnet 5 के एडेप्टिव थिंकिंग से उत्पन्न परिवर्तन केवल इतना नहीं है कि मॉडल कुछ समय और सोचे।

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

संदर्भ लिंक: https://platform.claude.com/docs/en/build-with-claude/effort

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

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

संदर्भ लिंक: https://platform.claude.com/docs/en/build-with-claude/effort

इसलिए effort केवल thinking की लंबाई को नियंत्रित नहीं करता, बल्कि एक Agent कार्य के लिए कितना विस्तार अनुमत है, इसे निर्धारित करता है। इससे Anthropic के मॉडल की परतों में सीधा परिवर्तन होगा।

यदि एक सामान्य coding कार्य Opus के लिए पहले से ही कठिन नहीं है, तो effort बढ़ाने के बाद, Opus शायद जल्दी ही प्रदर्शन प्लेटफॉर्म क्षेत्र में प्रवेश कर जाएगा। Fable के पास चाहे जितना भी मजबूत बेस मॉडल हो, उसके पास कम से कम अंतर्निहित कठिनाईयाँ हैं जिन्हें स्पष्ट अनुभव के अंतर में बदला जा सके।

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

संदर्भ लिंक: https://www.anthropic.com/news/claude-opus-5

इसका मतलब है कि उच्च-स्तरीय मॉडल द्वारा बेची जा रही चीजें बदल रही हैं। यह अब केवल “इस चक्र का उत्तर अधिक मजबूत है” नहीं बेच रहा है, बल्कि अधिक जटिल ट्रैजेक्टरी में अतिरिक्त विश्वसनीयता है।

समस्या यह है कि इस लाभ को फैलाने के लिए कार्य पर्याप्त लंबा होना चाहिए, और जैसे ही कार्य लंबा हो जाता है, मॉडल क्षमता एकमात्र निर्णायक कारक नहीं रहती, और संदर्भ स्थिति महत्वपूर्ण स्थान पर आ जाती है।

03

1M कॉन्टेक्स्ट देखकर इसे एक विशाल कार्य स्मृति के रूप में समझना आसान है, इसलिए जब Claude केवल 200K या 300K टोकन का उपयोग करके ही लापता होना, दोहराना या स्थिति भ्रम पैदा करता है, तो यह बहुत अप्रत्याशित लगता है।

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

संदर्भ लिंक: https://platform.claude.com/docs/en/build-with-claude/context-windows

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

यहाँ समस्या केवल retrieval तक सीमित नहीं है। मॉडल को केवल वर्तमान कार्य से संबंधित जानकारी ढूंढनी होगी, बल्कि यह भी निर्णय लेना होगा कि यह जानकारी अभी भी मान्य है या नहीं।

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

डेटाबेस वर्जन नंबर, अपडेट समय, लेन-देन और स्पष्ट क्षेत्रों के माध्यम से वर्तमान स्थिति को बनाए रख सकता है, जबकि प्राकृतिक भाषा संदर्भ में आमतौर पर ऐसी संरचना नहीं होती। यह अधिक लगभग append-only log के समान है, जहां मॉडल को घटनाओं के क्रम से वर्तमान दुनिया क्या है, इसे स्वयं पुनर्स्थापित करना होता है।

संदर्भ लिंक: https://platform.claude.com/docs/en/build-with-claude/context-windows

इसलिए, लंबे संदर्भ की जटिलता token उपयोग के अनुपात के साथ सरलता से संबंधित नहीं होती है। 250K token का स्थिर दस्तावेज़ 250K token के Agent इतिहास की तुलना में काफी अधिक आसानी से संभाला जा सकता है, क्योंकि बाद में में बहुत सारे संशोधित ऑब्जेक्ट, चरणबद्ध निर्णय, उपकरण परिणाम और अमान्य स्थितियाँ शामिल होती हैं।

Thinking history इस जटिलता को और बढ़ाएगा। सत्र में सिर्फ “क्या हुआ” ही नहीं, बल्कि “उस समय ऐसा क्यों निर्णय लिया गया” भी संग्रहित हो सकता है। यदि प्रारंभिक reasoning एक ऐसी मान्यता पर आधारित है जिसे बाद में खारिज कर दिया गया है, तो वह तर्क अभी भी वर्तमान प्रश्न के साथ अत्यधिक संबंधित होने के कारण भविष्य के निर्णयों में शामिल हो सकता है।

तो 1M कॉन्टेक्स्ट की वास्तविक सीमा केवल इतनी नहीं है कि कितनी जानकारी रखी जा सकती है, बल्कि यह है कि जब एक ही ऑब्जेक्ट के बढ़ते हुए इतिहास के संस्करण आते रहें, तो मॉडल अभी के संस्करण को स्थिरता से पुनर्स्थापित कर सकता है या नहीं।

04

जब context बढ़ता रहता है, तो compaction एक प्राकृतिक तरीका लगता है: पुराने इतिहास को संक्षिप्त करें और आगे बढ़ें। लेकिन Agent स्थितियों में compaction सामान्य सारांश के समान नहीं है।

एक उदाहरण को सारांशित करते समय छोड़ देना आमतौर पर केवल जानकारी की पूर्णता को प्रभावित करता है; एजेंट की ट्रैजेक्टरी को संक्षिप्त करते समय, एक अभी भी वैध सीमा को छोड़ देना, आगे के निष्पादन मार्ग को सीधे बदल सकता है।

संदर्भ लिंक: https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

कंपैक्शन को हल करना है “कौन सी चीजें महत्वपूर्ण हैं” नहीं, बल्कि “कौन सी चीजें अभी भी मान्य हैं”। एक इतिहास में एक साथ पूर्ण हो चुके कार्य, बाद में रद्द किए गए निर्णय, वर्तमान में लागू इंटरफ़ेस सीमाएँ, समाप्त हो चुके परीक्षण परिणाम और अस्थायी कार्यवाहियाँ हो सकती हैं। कंपैक्टर को इन समय-आधारित स्थितियों को एक ऐसे प्रतिनिधित्व में पुनः व्यवस्थित करना होगा जिससे अगला चक्र आगे बढ़ सके।

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

इसलिए compaction का मुख्य सूचक दबाव दर नहीं, बल्कि स्थिति की विश्वसनीयता है। यही कारण है कि Git, परीक्षण, कार्य फ़ाइलें, मेमोरी और संरचित हस्तांतरण लंबे समय तक चलने वाले Agent में अधिक महत्वपूर्ण हो रहे हैं।

वे केवल मॉडल के द्वारा देखे जाने वाले जानकारी को बढ़ाने नहीं हैं, बल्कि कुछ लंबे समय तक लागू होने वाली स्थितियों को प्राकृतिक भाषा इतिहास से बाहरी प्रणाली में स्थानांतरित कर रहे हैं। Git वर्तमान कोड संस्करण को स्पष्ट करता है, परीक्षण जांचने योग्य परिणाम देता है, कार्य फ़ाइलें पूर्णता को रिकॉर्ड करती हैं, और संरचित स्थिति वर्तमान निष्कर्ष और ऐतिहासिक प्रयासों को अलग करती है।

संदर्भ धनवान इतिहास को बनाए रख सकता है, लेकिन लंबे समय तक सभी स्थिति प्रबंधन की जिम्मेदारी नहीं ले सकता।

संदर्भ लिंक: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

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

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

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

ये असामान्यताएँ वास्तविक हैं, लेकिन वे मूल बग के प्राकृतिक परिणाम नहीं हैं, बल्कि पिछले संशोधन द्वारा उत्पन्न की गई हैं। इससे एजेंट एक विशेष विफलता मोड में चला जाता है: मॉडल अपने द्वारा बनाई गई डेटा वितरण का विश्लेषण करना शुरू कर देता है।

संदर्भ लिंक: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

यदि यह पहचान सकता है कि "ये नए त्रुटियाँ पिछले संशोधन के बाद उत्पन्न हुईं", तो यह पिछले स्थिति में वापस जा सकता है और मूल अनुमान की पुनर्जांच कर सकता है; यदि इस कारण-परिणाम संबंध की स्थापना नहीं की गई है, तो नए त्रुटियों को अलग-अलग समस्याओं के रूप में देखा जा सकता है और एक के बाद एक उन्हें ठीक किया जा सकता है।

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

Git diff वह मॉडल को बता सकता है कि कौन से परिवर्तन हाल ही में हुए हैं, परीक्षण यह सत्यापित कर सकते हैं कि कोई व्यवहार खराब तो नहीं हुआ है, checkpoint और rollback त्रुटि के फैलाव को सीमित कर सकते हैं, और स्वतंत्र evaluator मॉडल की अपनी व्याख्या के अलावा अतिरिक्त जांच प्रदान कर सकता है।

इन घटकों का उद्देश्य, मूल रूप से, एजेंट को बंद लूप त्रुटि सुधार क्षमता प्रदान करना है।

संदर्भ लिंक: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

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

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

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

ये सूचक यह नहीं मापते कि एक प्रतिक्रिया कितनी बुद्धिमानी से है, बल्कि यह मापते हैं कि एक ट्रैजेक्टरी को नियंत्रित रखा जा सकता है या नहीं।

इस प्रकार, एंथ्रोपिक द्वारा हाल ही में उजागर किए गए कई मुद्दे वास्तव में विभिन्न स्तरों पर आते हैं। इन मुद्दों के एकत्रित होने के बाद, क्लॉड की तकनीकी सीमाएँ भी बदलने लगी हैं।

पहले यह पूछना अधिक था कि मॉडल किसी विशिष्ट प्रश्न को हल कर सकता है या नहीं, अब यह अधिक कठिन है कि जब कार्य कई घंटे चलता है, दर्जनों टूल कॉल्स, कई स्टेट कंप्रेशन और कई कोड संशोधनों के बाद, सिस्टम अभी भी एक विश्वसनीय वर्तमान दुनिया बनाए रख सकता है।

मॉडल क्षमताएँ लगातार बढ़ रही हैं, और केवल प्रत्येक चरण के निर्णय की सीमा को ही बढ़ाया जा सकता है। जबकि लंबे Agent का स्थिरता से काम करना अब एक अलग क्षमता पर निर्भर करता है: क्या स्थिति स्पष्ट है, क्रियाएँ सत्यापित की जा सकती हैं, और त्रुटियाँ पलटी जा सकती हैं।