एक कोडिंग एजेंट का लंबा कार्य एक अनुरोध नहीं, बल्कि दर्जनों होते हैं: मॉडल कॉल, टूल कॉल, फ़ाइल संपादन, टेस्ट के बार-बार चलने। और लगभग हर ऐसे रन पर यह ख़्याल आता है: क्या अभी मॉडल बदल दिया जाए?
चलते-चलते स्विच करना फ़ायदेमंद क्यों लगता है
अर्थशास्त्र यहाँ सीधा है। मज़बूत मॉडल प्रति टोकन महँगा है, पर बेहतर सोचता है। कमज़ोर सस्ता है, पर मुश्किल पर अटक जाता है। इससे दो स्वाभाविक चालें निकलती हैं:
- एस्केलेशन — जब सस्ता मॉडल अटक जाए, तो महँगा और ताक़तवर जोड़ दें।
- डाउनग्रेड — जब मुश्किल हिस्सा पीछे रह जाए, तो सस्ते पर लौट आएँ ताकि रूटीन पर ज़्यादा ख़र्च न हो।
कागज़ पर हाइब्रिड मार्ग आदर्श दिखता है: महँगे मॉडल का भुगतान सिर्फ़ वहीं होता है जहाँ वह सचमुच ज़रूरी है। पर एजेंट अगले मॉडल को सिर्फ़ फ़ाइलें और रेपो की स्थिति नहीं सौंपता। वह इतिहास सौंपता है: तर्क की शृंखला, टूल के आउटपुट, बंद गलियों की कोशिशें, बीच के फ़ैसले। लेने वाला पक्ष उस प्रक्षेपवक्र को आगे बढ़ाता है जो किसी और मॉडल ने बनाया — अलग शैली, अलग विस्तार-स्तर, अलग आदतों के साथ। यही बात प्रीप्रिंट «The Handoff Tax: Continuing Non-Native Trajectories in LLM Agents» (arXiv:2608.24358, 25 अगस्त 2026) के लेखक उठाते हैं।
प्रयोग कैसे बनाया गया
यह काम मॉडलों के जोड़ों पर टिका है: सस्ते और कम सक्षम (लेख में LC, low cost) बनाम महँगे और ज़्यादा मज़बूत (HC, high cost)। जोड़ दो परिवारों से लिए गए — Claude और GPT, यानी जाँच एक वेंडर पर नहीं, दो पर एक साथ हुई, जो निष्कर्षों का महत्व साफ़ तौर पर बढ़ाती है।
तीन चीज़ें बदली गईं:
- दिशा — ऊपर की ओर, ज़्यादा मज़बूत मॉडल की तरफ़, और नीचे की ओर, कमज़ोर की तरफ़।
- क्षण — लंबे कार्य के भीतर स्विच करने का समय।
- संदर्भ सौंपने का प्रारूप — जिसे लेखक इंटरफ़ेस कहते हैं।
आख़िरी बिंदु सबसे दिलचस्प है। तीन विकल्पों की तुलना हुई: पूरे प्रक्षेपवक्र का पूरा हस्तांतरण, कॉम्पैक्शन (इतिहास से संकुचित सार), और प्रक्षेपवक्र हटाकर सिर्फ़ रेपो की स्थिति बनाए रखना। दूसरे शब्दों में, सवाल यह था: नए मॉडल को दूसरे की कितनी «सोच» दिखाना वाक़ई लायक़ है?
मुख्य नतीजा: हस्तांतरण पर कर
निष्कर्ष संयमित करने वाला निकला। एस्केलेशन में इतिहास का पूरा हस्तांतरण कमज़ोर और मज़बूत मॉडल के बीच के गुणवत्ता-अंतर का आधे से भी कम पाटता है — और साथ में लागत पर महसूस होने वाला अतिरिक्त बोझ आता है। यानी आप महँगे मॉडल के दाम चुकाते हैं, पर उसका फ़ायदा सिर्फ़ कुछ हिस्सा पाते हैं। इसी अंतर को लेखकों ने handoff tax कहा — नियंत्रण सौंपने का कर।
और यह किसी एक वेंडर की ख़ामी नहीं: तस्वीर दोनों परिवारों में दोहराई गई। तर्कसंगत व्याख्या यह है — मज़बूत मॉडल अपना संदर्भ दूसरे की भूलभुलैया समझने में ख़र्च करता है, पूर्ववर्ती की ग़लत धारणाएँ कुछ हद तक अपना लेता है, और ख़ाली शुरुआत के बजाय बोझ के साथ शुरू करता है। उसकी कुछ क्षमता काम हल करने के बजाय «दूसरे की डायरी पढ़ने» में चली जाती है।
असममिति: नीचे — हाँ, ऊपर — शर्तों के साथ
सबसे उपयोगी अवलोकन यह है कि कर सममित नहीं है। डाउनग्रेड ने उलटे, कीमत और गुणवत्ता के अनुपात में फ़ायदेमंद बिंदु दिया: मुश्किल तर्क पूरा होने के बाद सस्ते मॉडल पर स्विच करना काम करता है।
और भी दिलचस्प यह है कि संदर्भ सौंपने का पसंदीदा प्रारूप दिशा के हिसाब से उलटा हो जाता है:
- एस्केलेशन में कमज़ोर मॉडल के प्रक्षेपवक्र की जानकारी घटाना ज़्यादा मदद करता है। कम कचरा — साफ़ शुरुआत।
- डाउनग्रेड में मज़बूत मॉडल का प्रक्षेपवक्र हटाना गुणवत्ता घटा देता है। यहाँ इतिहास सहारे का काम करता है, और उसे बनाए रखना चाहिए।
व्याख्या यह सुझाती है: कमज़ोर मॉडल के पीछे बंद गलियों का निशान रहता है, और मज़बूत को वह सिर्फ़ बाधित करता है। जबकि मज़बूत के पीछे सुविचारित योजना और सही फ़ैसले रहते हैं, जिन पर कमज़ोर पटरी की तरह चल सकता है। यह मेरी व्याख्या है, लेख का शब्दशः निष्कर्ष नहीं, पर आँकड़ों से अच्छी तरह मेल खाती है।
व्यवहार में क्या करें
व्यावहारिक निष्कर्ष ये निकलते हैं:
- जितना मन करे उससे कम स्विच करें। हर स्विच मुफ़्त क्रिया नहीं, अज्ञात कीमत वाला सौदा है।
- सीमा पर एस्केलेट करें, «अटक जाने पर» नहीं। अच्छा बिंदु एक पूरा हुआ चक्र है जिसमें साफ़ विफलता हो (जैसे टेस्ट लगातार फेल हो रहे हों), न कि सोच का बीच।
- ऊपर — संकुचित करें, नीचे — सहेजें। मज़बूत मॉडल को सौंपने से पहले संक्षिप्त सार तैयार करें: क्या हो चुका, क्या काम नहीं आया, कौन-सी सीमाएँ हैं। कोशिशों की पूरी प्रतिलेख रखना ठीक नहीं।
- नीचे उदारता से दे सकते हैं। कमज़ोर मॉडल के लिए योजना और मज़बूत के छोड़े संपादन देखना उपयोगी है।
- अपना कर गिनें। एस्केलेशन में «पूरा इतिहास» और «कॉम्पैक्शन» के बीच का अंतर एक तैयार A/B-टेस्ट है, जिसे अपने कार्यों पर चलाना लायक़ है: यह सस्ता है और जल्दी दिखा देता है कि आप कर चुका रहे हैं या नहीं।
एक अलग ख़्याल: कभी-कभी बीच में मॉडल बदलना ही नहीं, ज़्यादा सस्ता पड़ता है। अगर मज़बूत की ज़रूरत सिर्फ़ योजना बनाने में है, तो भूमिकाएँ पहले से बाँट देना ज़्यादा तर्कसंगत है — योजना मज़बूत से, निष्पादन कमज़ोर से — बजाय एक ही प्रक्षेपवक्र के भीतर नियंत्रण सौंपने के।
निष्कर्ष
कार्य के बीच मॉडल बदलना बजट-अनुकूलन का मुफ़्त लीवर नहीं, बल्कि अपनी कीमत वाली क्रिया है। दूसरे का प्रक्षेपवक्र सौंपना उस फ़ायदे का हिस्सा खा जाता है जिसके लिए आप भुगतान करते हैं। इस अर्थ में एस्केलेशन जितना लगता है उससे ज़्यादा जोखिम भरा है; डाउनग्रेड उलटे, अनुमानित तरीक़े से काम करता है। और मुख्य व्यावहारिक तरीक़ा मॉडल चुनने में नहीं, बल्कि यह चुनने में है कि आप उस मॉडल को क्या दिखाते हैं। नतीजे कोडिंग एजेंटों और मॉडलों के ख़ास जोड़ों पर मिले हैं, इसलिए उन्हें हर परिदृश्य पर ज्यों का त्यों लागू नहीं किया जाना चाहिए — पर अपने मापों के लिए कार्यकारी परिकल्पना के तौर पर वे पूरी तरह उपयुक्त हैं।
