Tokenmaxxing मर चुका है, Tokenmaxxing अमर रहे
(12gramsofcarbon.com)- कंपनियों में AI अपनाने के शुरुआती दौर में token usage को performance evaluation से जोड़ने वाला tokenmaxxing बेकार लागत पैदा करता था, लेकिन इसने AI tools के इस्तेमाल को संगठन में ज़बरदस्ती फैलाने की भूमिका भी निभाई
- Meta में जब प्रति-व्यक्ति token usage को evaluation से जोड़ा गया, तो token numbers बढ़ाने के लिए दो agents को पूरे दिन आपस में बात करवाने जैसी औपचारिक usage भी दिखाई दी
- पहले लंबे समय तक agents चलाना छोटे-छोटे errors के जमा होने वाली compounding error की वजह से जोखिम भरा था, लेकिन हाल में compounding correctness का रुझान उभर रहा है, जहाँ ज़्यादा tokens बेहतर नतीजे ला सकते हैं
- security क्षेत्र में Mythos जैसे models पर बड़ा token budget लगाकर vulnerabilities खोजने का तरीका सामने आया है, और ऐसी संरचना बन रही है जहाँ defenders को attackers से ज़्यादा compute खर्च करना पड़ता है
- आगे चलकर महंगे top-tier models पर असीमित खर्च करने के बजाय, सस्ते open models को loop में ज़्यादा बार चलाना tokenmaxxing का व्यावहारिक केंद्र बन सकता है
निरर्थक token खपत से शुरू हुआ tokenmaxxing
- tokenmaxxing उस स्थिति को कहता है जहाँ executives कर्मचारियों को ज़्यादा tokens खर्च करने के लिए प्रेरित करते हैं, और नतीजतन कम वास्तविक value वाले कामों पर भी tokens खर्च होने लगते हैं
- एक प्रमुख उदाहरण के तौर पर Meta पर यह आलोचना हुई कि उसने performance evaluation को प्रति-व्यक्ति token usage से जोड़ा
- Meta के एक कर्मचारी ने बताया कि token number बढ़ाने के लिए उसने दो agents को पूरे दिन एक-दूसरे से बात करने दी
- ऊपर से देखने पर यह ऐसा लग सकता था कि management बिना revenue के सिर्फ लागत जला रही है, लेकिन इसे AI tools के उपयोग को ज़बरदस्ती फैलाने वाली policy के रूप में भी देखा जा सकता है
- कुछ महीने पहले तक संगठनों के भीतर कई senior लोग AI tools के इस्तेमाल का कड़ा विरोध करते थे, और मनाने में सफलता मिलने पर भी अक्सर tools का उपयोग अजीब या खराब नतीजे देने वाले तरीकों से किया जाता था
- ऐसी स्थिति में ऊपर से आया token usage का दबाव दीवार तोड़ने के लिए भोंडा बाध्यकारी साधन की तरह काम करता था
लागत के दबाव में खत्म हुई पहली unlimited usage policy
- tokenmaxxing policy ने कुछ हद तक असर दिखाया, और अब लगभग हर टीम कम से कम थोड़ा बहुत AI के साथ coding कर रही है
- कई टीमें अभी भी Ramp Inspect या Stripe Minions जैसे अपने systems नहीं बना पाई हैं, लेकिन वे कम से कम sidebar में Cursor इस्तेमाल करने के स्तर तक पहुँच चुकी हैं
- token usage में तेज़ बढ़ोतरी के बीच OpenAI और Anthropic, listing की तैयारी करते हुए, subscription limits घटा रहे हैं और API prices बढ़ा रहे हैं
- token subsidies भी घट रही हैं, इसलिए कुछ टीमें unlimited token usage policies वापस ले रही हैं
- पुराने अर्थ वाला unlimited tokenmaxxing अब उस चरण के करीब है जहाँ cost review झेलना मुश्किल होगा
compounding error से compounding correctness तक
- AI tools से उम्मीद यह है कि वे बिना लगातार मानवीय supervision के कठिन और उबाऊ काम संभालें
- बड़े पैमाने की code migration
- हर सुबह competitor research
- inbound और outbound flows का processing
- पहले AI को लंबे समय तक चलाने पर model की छोटी गलतियाँ और hallucinations project में जमा होती जाती थीं और उन्हें पलटना मुश्किल हो जाता था
- इस phenomenon को compounding error कहा जाता था, और चूँकि इसमें काफी मानवीय supervision चाहिए होती थी, इसलिए agents को 24 घंटे चलाने का कारण भी कम था
- अब माहौल compounding correctness की ओर बदल रहा है, जहाँ ज़्यादा tokens खर्च करने से सही उत्तर मिलने की संभावना बढ़ सकती है
- अगर token spending नतीजों की quality से जुड़ती है, तो फिर से ज़्यादा tokens खर्च करने की incentive पैदा होती है
security क्षेत्र में पहले दिखती token budget की प्रतिस्पर्धा
- cyber security में पहले ही ऐसे उदाहरण सामने आ रहे हैं जहाँ token spending सीधे performance से जुड़ती है
- Cybersecurity is Proof of Work Now में Anthropic के Mythos का उदाहरण देते हुए कहा गया है कि systems को मजबूत करने के लिए attackers जितने tokens exploitation में खर्च करते हैं, defenders को vulnerabilities खोजने में उससे ज़्यादा tokens खर्च करने होंगे
- AISI ने Mythos की हर कोशिश के लिए 100M tokens का budget तय किया, जो प्रति प्रयास $12,500 और 10 runs के लिए $125,000 बनता है
- 100M token budget पाने वाले models में diminishing returns के संकेत नहीं दिखे, और AISI ने कहा कि test किए गए token budget range में budget बढ़ने के साथ models लगातार प्रगति करते रहे
- इस संरचना में चतुराई से अधिक compute workload और भुगतान करने योग्य token budget महत्वपूर्ण हो जाता है
loops और लंबे समय तक agent execution
- Boris Cherny ने Claude Code के मंच पर loops के बारे में जो बात कही, वह भी इसी रुझान से जुड़ती है
- loops की बुनियादी संरचना यह है कि agent अपने turn के खत्म होने तक चलता है, और खत्म होने पर उसी prompt को फिर से शुरू किया जाता है
- इससे भारी specifications को अपने-आप बाँटा जा सकता है और agent समय के साथ हिस्सों में समस्याएँ सुलझा सकता है
- यह विचार नया नहीं है; यह पिछले साल जुलाई से मौजूद था और कभी इसे “Ralph Wiggum loop” कहा जाता था
- पहले इसके लिए prompt design और agent behavior की गहरी समझ चाहिए होती थी, लेकिन compounding correctness की वजह से अब दोहराव के साथ बेहतर होते अनुमानित नतीजों की उम्मीद करना आसान हो रहा है
open models से बनती लागत-प्रभावी दोहराव वाली execution
- लंबी अवधि में tokenmaxxing का विजेता open model platforms हो सकते हैं
- top-tier lab models पर भारी token spending वाला तरीका CFO review से गुजरना मुश्किल पाता है
- जैसे-जैसे open models बेहतर होते जाएँगे, सस्ते models को loops में ज़्यादा बार चलाने का तरीका और आकर्षक बनता जाएगा
- उदाहरण के लिए, अगर Claude हर iteration में 1.1x improvement देता है और GLM 5.2 1.05x improvement देता है लेकिन लागत लगभग पाँचवाँ हिस्सा है, तो GLM 5.2 loop को 5 गुना ज़्यादा चलाना बेहतर हो सकता है
- “Other things” section में भी GLM 5.2 को state-of-the-art नहीं, लेकिन frontier models की तुलना में बहुत सस्ता बताया गया है
- GLM 5.2: input के प्रति 1 million tokens पर लगभग $1.4, output के प्रति 1 million tokens पर लगभग $4
- Opus 4.X series: input के प्रति 1 million tokens पर $5, output के प्रति 1 million tokens पर $25
- Haiku 4.5: input के प्रति 1 million tokens पर $1, output के प्रति 1 million tokens पर $5
- कहा गया है कि GLM 5.2, Haiku से मजबूत है, और कुछ benchmarks में GPT 5.5 से भी बेहतर हो सकता है
developer spending और pipeline spending में फर्क
- tokenmaxxing के दो अलग रूप हैं
- पहला है developers के लिए token spending
- developers Claude Code जैसे tools इस्तेमाल करते हैं, loops चलाते हैं, और बहुत tokens खर्च करते हैं
- अगर इससे engineer productivity बढ़ती है, तो यह अच्छा खर्च हो सकता है
- दूसरा है pipelines के लिए token spending
- developers अब भी हाथ से code लिखते हैं और उसी code से खास tasks के लिए one-off agents बनाते हैं
- ये agents non-deterministic और fragile तरीकों से काम करते हुए बहुत tokens खर्च करते हैं
- यह तभी अच्छा खर्च है जब pipeline वास्तव में काम करे, लेकिन ऐसे agents deterministic pipelines जितने accurate नहीं रहे हैं
- hallucination की लागत घटाने के लिए quality-check agents जोड़ें, और फिर उन check agents की गलतियाँ पकड़ने के लिए एक और agent लगाएँ, तो token cost 3 गुना हो जाती है
- one-off pipeline-style tools को अब task-specific agents की बजाय, खास tasks के लिए लिपटे हुए general-purpose platforms की तरह handle करने का रुझान बढ़ रहा है
software factory और चरम token spending
- इसका स्वाभाविक अंतिम बिंदु software factory है, और उससे आगे dark factory
- इस संरचना में codebase बिना मानवीय supervision के code बनाता है, review करता है, bugs ठीक करता है, और tests लिखता है
- इंसान की भूमिका सिर्फ specification डालने और application पाने तक सीमित रह जाती है
- StrongDM की software factory का उल्लेख इस दिशा को चरम तक ले जाने वाले उदाहरण के रूप में किया गया है
- StrongDM की ओर से यह दावा किया गया कि engineers को प्रति दिन $1000 के tokens खर्च करने का लक्ष्य रखना चाहिए, लेकिन इसे अतिशयोक्ति और प्रचारात्मक रुख के रूप में आंका गया है
- कहा गया है कि उनकी अपनी software factory लगभग $600 प्रति माह खर्च करती है, और अभी प्रति engineer एक senior Google engineer के बराबर token cost खर्च करना बहुत ज़्यादा माना जाता है
- फिर भी tokens पर बड़ा पैसा खर्च करने की incentive संभावित रूप से मौजूद है, और अभी उसके व्यापक होने का इंतज़ार है
1 टिप्पणियां
Hacker News की रायें
Tokenmaxxing बस कर्मचारियों को AI का अर्थपूर्ण उपयोग करने के लिए मजबूरन शिफ्ट कराने का तरीका था
जो कंपनियां token खर्च से performance माप रही थीं, वे अब उसकी intensity कम कर सकती हैं। कर्मचारियों ने उन कामों में भी AI आजमाकर सीखा, जहां पहले वे AI का इस्तेमाल नहीं करते, कि क्या संभव है और क्या नहीं
कोई भी इतना मूर्ख नहीं है कि token खर्च को हमेशा performance metric बनाए रखे और unlimited budget दे। मुझे लगता है कि यह शुरुआत में कर्मचारियों को नए माहौल में ले जाने के लिए एक अस्थायी कदम था
Management को लगा कि कर्मचारी AI को पर्याप्त तेजी से नहीं अपना रहे हैं, इसलिए 2025 में CEOs द्वारा AI इस्तेमाल न करने पर नौकरी से निकालने की धमकी देने वाली mainstream खबरें भी बहुत थीं। Tokenmaxxing उसका उल्टा चरम था, और कंपनियां आखिरकार किसी संतुलन पर पहुंचेंगी
इस पर बहुत गहराई से सोचने की जरूरत नहीं
साथ ही, एक reply ने इस X पोस्ट को उदाहरण के तौर पर दिया कि management को ऐसे कदम क्यों उठाने पड़े। सैकड़ों/हजारों/दसियों हजार लोगों वाली कंपनी को बदलना मुश्किल है, और एक बार में एक सरल संदेश ही भेजना पड़ता है। https://x.com/danluu/status/1487228574608211969?lang=en
असल में यह ज्यादा ऐसा लगता है कि value creation की असली जगह से बहुत दूर बैठे, जरूरत से ज्यादा paid management layer ने LLM की कमियों को समझे बिना अंधाधुंध trend follow किया
ज्यादातर कंपनियां, अच्छे से अच्छे में, “बाकी लोग कर रहे हैं तो हम भी करें” पर केंद्रित थीं, और बुरे हाल में यह “देखें कि क्या developer Joe पूरी टीम जितना productive हो सकता है और फिर बाकी लोगों को निकाल दें” जैसा था
असल में कई कंपनियों ने “token खर्च कम है, इसलिए performance कम है” के कारण कर्मचारियों की बड़ी छंटनी भी की
इस खास management मूर्खता के मामले में यह शायद सीधे लागू हो सकती है, लेकिन व्यापक तौर पर देखें तो यह सचमुच सुंदर लेखन है
काश मैं किसी इंसान के बारे में, CEO तो दूर की बात है, इतनी भटकी हुई आस्था रख पाता
तब किसी junior ने कहा था कि उसकी कंपनी ने A/B testing में “Tokenmaxxing” जैसा system लागू किया था। जितने ज्यादा tests, performance review में उतना फायदा। उस समय यह मूर्खतापूर्ण लगा था, लेकिन आखिर में इसका असर यह हुआ कि सभी experiment क्या है और उसे कैसे चलाते हैं, इससे परिचित हो गए
लेकिन बड़ी कंपनी में manager पर VP से AI करना ही है का दबाव आया होगा, और VP पर executives से दबाव आया होगा। Executives पर शायद ऐसा AI strategy पेश करने का दबाव रहा होगा जो खर्च घटाते हुए कंपनी को अनंत तक scale करने वाली कोई विश्वसनीय जादुई चीज लगे
ऐसे माहौल में Gartner charts copy-paste करना, conferences से सुने buzzwords मिलाना, और उम्मीद करना कि कहीं कोई व्यक्ति कभी इसे आगे बढ़ते हुए दिखने वाली किसी चीज में बदल देगा—यह ज्यादा plausible है
“अब बात अलग है, agents errors नहीं बल्कि success accumulate करते हैं” यह बात कम से कम 1 साल से सुन रहा हूं, लेकिन अभी ऐसा दिखता नहीं
ऐसा कहने वालों से संयोग से प्रति व्यक्ति 50,000 डॉलर वाली 1 हफ्ते की AI training मिली, और उसमें से जो कुछ concrete recommendations सच में मददगार थीं, उनमें से एक थी context को बार-बार clear करते रहना ताकि काम पटरी से न उतरे
हालांकि security vulnerabilities खोजने में शायद इससे फर्क न पड़े। Tokenmaxxing उस use case में निश्चित रूप से प्रभावी है। Industry अभी बहुत महंगी और जटिल continuous fuzzing अपनाने की प्रक्रिया में है
पहले जिन tools में ऐसी functionality थी, Zed और बाद में नाम दिए गए Text Threads, उन्होंने भी अब वह feature हटा दिया है
सोच रहा हूं कि आखिर वह कौन था जिसके लिए किसी ने सोचा कि ऐसा investment worth it होगा
“कल्पना कीजिए कि कोई serious business leader, जैसे Mark Zuckerberg, घोषणा करे कि Meta पैसा जलाने वाली है” वाली बात कुछ वैसी ही है जैसे metaverse pivot की घोषणा करना और गंभीरता दिखाने के लिए कंपनी का नाम तक बदल देना
“ज्यादा tokens इस्तेमाल करने से आम तौर पर बेहतर results मिलते हैं। हम इसे ‘accuracy का compounding’ कहते हैं” वाला हिस्सा अजीब है
क्या हम सच में उस phase में पहुंच गए हैं? क्या आम तौर पर यह सही है कि जितने ज्यादा tokens इस्तेमाल करें, results उतने बेहतर होते हैं? यह राय इतनी अजीब है कि लगता है लेखक को Tokenmaxxing से financial gain हो रहा होगा
यह नर्क जैसा है। अगर नर्क वह जगह हो जहां आप हमेशा के लिए खराब maintenance वाले असुविधाजनक roller coaster में फंसे हों, तो बिल्कुल यही feeling है
लेख के लिए ज्यादा उपयुक्त title शायद “Tokenmaxxing की मौत की खबरें बहुत बढ़ा-चढ़ाकर कही गई हैं” होता
निजी तौर पर मुझे “x मर चुका है, x अमर रहे” जैसे बेतुके title idiom का इस्तेमाल पसंद नहीं
यहां loop से क्या मतलब है? क्या मतलब एक ही prompt को तब तक repeat करना जब तक desired result न आए? क्या repeated results एक-दूसरे से बहुत मिलते-जुलते नहीं होंगे?
https://github.com/topics/loop-engineering
वह criteria अक्सर सिर्फ updated to-do list होता है। ऐसे बेहद simple “harness” में से एक को तो उससे पैदा होने वाली दिमाग-खाली लेकिन जिद्दी Tokenmaxxing का मजाक उड़ाने के लिए Ralph Wiggum Loop[1] तक कहा गया
[1] https://awesomeclaude.ai/ralph-wiggum
लगता है बड़ी technology adoption के शुरुआती कुछ वर्षों में ऐसी चीजें ज्यादातर बार दोहराई जाती हैं
2010 के शुरुआती दशक के big data boom में भी executives ने clear analytics use cases या governance के बिना ही Spark clusters और data lakes खरीदने शुरू कर दिए थे
“किसी enterprise leader को सिर्फ अच्छा महसूस करने के लिए पैसा जलाने की बात कहते शायद ही कभी सुना है”—सच में?
करीब 4 साल पहले हमारे CEO ने team building exercises के लिए consultants को कई बार flight से बुलवाया। हम 3-year server replacement तक afford नहीं कर सकते, लेकिन उन consultants का खर्च बिना समस्या के दे दिया गया
हाल ही में branding consultants भी बुलाए गए, और सारी photos rebrand करने में AWS costs पर हजारों डॉलर खर्च किए गए। हम captive market में operate करते हैं। हमारे market में sales करनी हो तो हमारी service subscription जरूरी है, और उस market से बाहर हों तो subscribe कर भी नहीं सकते। आखिरकार branding ने revenue में 0 की बढ़ोतरी की
पहले जिस company में काम करता था, वहां नया CTO आते ही जिन शुरुआती कामों में से एक किया, वह था server naming convention। US-focused कर्मचारियों के लिए अपरिचित दुनिया भर के शहरों के नाम इस्तेमाल करने का तरीका था: database servers Swiss शहर, web servers Denmark, storage Finland वाले। cattle जैसे treated names से pet names में बदलाव हुआ, और वह CTO करीब 6 महीने टिके
मेरे अनुभव में company leadership उतनी मितव्ययी नहीं है जितनी यह लेख मानता है
corporate environment में काम करते हुए ऐसे waste के साफ उदाहरण कभी न देखे हों, यह कल्पना करना मुश्किल है। जरूरत से ज्यादा paid consultants और use-it-or-lose-it budgets इसके classic उदाहरण हैं
फिल्म Office Space 27 साल पहले आई थी, और उसके plot में ऐसे overpaid “efficiency consultants” का मजाक उड़ाया गया है जिनका काम बस management से लोगों को निकालने को कहना है
और अधिक सटीक रूप से, यह “इससे मेरे career को फायदा होगा” के करीब है