सभी कहते हैं कि Claude Code टोकन का बर्बादी करता है, वास्तव में कितना बर्बाद होता है? अब अंततः किसी ने संख्या निकाल ली है।
हाल ही में Composio टीम से एक दिलचस्प तुलनात्मक प्रयोग हुआ। उन्होंने एक ही मॉडल का उपयोग किया किमी K3, तीन अलग-अलग agent फ्रेमवर्क (harness) में चलाएं —— Claude Code, Hermes और किमी कोड—— कुल 28 समान कार्यों की जांच की गई।
परिणामस्वरूप, तीन हैरन्स द्वारा कार्य पूरा करने की सफलता की दर लगभग समान है: किमी कोड में 28 में से 22 सफल, हर्मीस में 21, क्लॉड कोड में 20। अंतर बहुत बड़ा नहीं है।
अंतर वास्तव में टोकन खपत से बनता है। एक ही कार्य को अलग-अलग हैरन्स के साथ चलाने पर, टोकन की खपत में अधिकतम 30 गुना का अंतर हो सकता है!
माध्यिका के अनुसार, किमी कोड लगभग 61,000 टोकन का उपयोग करता है, हर्मेस लगभग 67,000, जबकि क्लॉड कोड सीधे 3.4 लाख तक पहुँच जाता है, जो लगभग है किमी Code का 6 गुना।
दबाएं किमी K3 की कीमत 3 डॉलर प्रति मिलियन इनपुट टोकन है (एजेंट वर्कफ्लो में इनपुट टोकन आमतौर पर 95% तक होते हैं), प्रत्येक कार्य की औसत लागत लगभग है: किमी Code 0.22 डॉलर, Hermes 0.28 डॉलर, और Claude Code 2 डॉलर तक पहुँच गया। अंतर स्पष्ट है।
स्पीड भिन्न है। माध्यिका समय के अनुसार, Hermes सबसे तेज़ है, 179 सेकंड; किमी कोड 297 सेकंड; क्लॉड कोड 348 सेकंड।
इसलिए सबसे तेज़ Hermes है, और सबसे कम टोकन वाला किमी कोड, दोनों एक साथ नहीं आते हैं।
कंपोसियो टीम ने इससे एक सीधा निष्कर्ष निकाला: अगर आप एजेंट की लागत कम करना चाहते हैं, तो पहले देखें कि कौन सा हैरनेस उपयोग किया जा रहा है, और मॉडल बदलने के लिए जल्दी न करें। उनके डेटा के अनुसार, हैरनेस खुद ही लागत को 9 गुना तक अंतर कर सकता है, जबकि मॉडल की क्षमता में वास्तव में लगभग कोई अंतर नहीं है।
सेबास्टियन राश्का ने इस परिणाम को देखकर भी पोस्ट किया, जिसमें कहा कि यह उनके पिछले Qwen3.6 के साथ किए गए अवलोकन के समान है: क्लॉड कोड लगभग समान सफलता दर के साथ, टोकन उपयोग अन्य कई हैरन्स की तुलना में 2 से 3 गुना होता है।
उन्होंने कुछ संभावित कारणों का उल्लेख किया: क्या इसे कम अनुकूलित किया गया है? क्या इसमें बग है? या इसे जानबूझकर ऐसा डिज़ाइन किया गया है (क्योंकि अधिक कठिन कार्यों पर इसका लाभ हो सकता है)? उन्होंने कहा कि उन्हें इसे ध्यान से जांचने के लिए और समय देना होगा।
फिर उन्होंने पिछले महीने अपने स्थानीय coding agent लेख लिखते समय अपने अवलोकन का उल्लेख किया। उस समय उन्होंने विश्लेषण किया था कि Claude Code क्यों अधिक token का उपयोग करता है, और पाया कि अंतर मुख्य रूप से इनपुट token में था, न कि आउटपुट token में। अर्थात, Claude ने दोगुना सामग्री नहीं लिखी है। लॉग दर्शाते हैं कि Claude का harness बहु-चरणीय इंटरैक्शन में पिछले संदेश, टूल कॉल, कमांड आउटपुट और फाइल कंटेंट सहित अधिक संदर्भ को बार-बार मॉडल में भेजता है। एक उदाहरण के रूप में, किसी एक बार Claude के चलने के बाद लगभग 578,000 इनपुट token का उपयोग हुआ, लेकिन केवल लगभग 4,500 token का आउटपुट हुआ, जो 25 चरणों में फैला हुआ था। इसलिए, संभावित समझ यह है कि Claude का harness, बहु-चरणीय agent निष्पादन के दौरान, प्रॉम्प्ट-साइड हिस्ट्री को संचयीय रूप से बढ़ाता है या शामिल करता है।
ये परीक्षण परिणाम एक अनदेखा नहीं किया जा सकने वाला प्रवृत्ति प्रकट करते हैं: हार्नेस का महत्व मॉडल के खुद के बराबर हो गया है।
हाल ही में एक पेपर (Writer, एक एंटरप्राइज-लेवल AI एजेंट प्लेटफॉर्म कंपनी द्वारा) ने इसे व्यवस्थित रूप से दर्शाया: इसने कंट्रोल्ड वेरिएबल प्रयोगों के माध्यम से साबित किया कि मॉडल बदलने के बजाय हैरन्स स्तर बदलने से लागत कम होती है, और सभी मॉडल लाभान्वित होते हैं।
विशेष रूप से, उन्होंने एक कठोर “नियंत्रित चर” प्रयोग किया: 22 कार्यालयीन कार्यों और 6 बेस मॉडल्स (Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, Palmyra X6) को स्थिर रखते हुए, केवल ऑर्केस्ट्रेशन लेयर को बदला गया — पारंपरिक उत्पादन-स्तरीय एजेंट साइकिल को Writer के स्वयं के Harness से बदल दिया गया।
परीक्षण परिणाम दर्शाते हैं: प्रत्येक कार्य की औसत लागत 41% कम हो गई (0.21 डॉलर → 0.12 डॉलर), माध्यिका देरी 44% कम हो गई (48 सेकंड → 27 सेकंड), टोकन खपत 38% कम हो गई (14.2k → 8.8k), जबकि कार्य पूरा करने की गुणवत्ता लगभग समान रही (0.78 → 0.81, नमूना आकार छोटा होने के कारण इसे कोई महत्वपूर्ण अंतर नहीं माना जा सकता)। मूल्य प्रति लागत के मामले में, प्रति डॉलर लागत पर प्राप्त गुणवत्ता में 82% की वृद्धि हुई, और प्रति मिलियन टोकन पूरे होने वाले कार्यों की संख्या 54.9 से बढ़कर 92.0 हो गई।
तो, मॉडल "पानी, बिजली, गैस" बनने के बाद, क्या harness ही वह एसी है जो आपके बिजली बिल को निर्धारित करता है? दूसरे शब्दों में: पहले कोई कहता था "मॉडल ही उत्पाद है", अब क्या "harness ही उत्पाद है"?
चूंकि हार्नेस इतना महत्वपूर्ण है, तो क्या बाद के खाते भी अधिक विस्तार से लिखे जाने चाहिए?
कुछ लोगों ने इशारा किया है कि हमें मौजूदा benchmark में 'harness टैक्स' शामिल करना आवश्यक है। खासकर इस बात को ध्यान में रखते हुए कि जब टूल कॉल और पुनः प्रयास लूप में चले जाते हैं, तो यह टैक्स रेखीय रूप से नहीं बढ़ता।
दूसरे शब्दों में, भविष्य के एजेंट प्रतियोगिता के पहले हाफ में यह देखा जाएगा कि "क्या यह किया जा सकता है", और दूसरे हाफ में यह होगा कि "एक ही काम करने में कौन अधिक सस्ता है" — और पैसे बचाने का रहस्य मॉडल में नहीं, हार्नेस में है।
एजेंट चलाते समय, क्या आपको ऐसा कोई अनुभव हुआ है? टिप्पणी अनुभाग में चर्चा करें।
यह लेख वेचेन ग्रुप "मशीन एक्सपर्ट" (ID: almosthuman2014) से आया है, लेखक: मशीन एक्सपर्ट