टोकन compression का भ्रम: RTK को लेकर मैं संशय में क्यों हूँ

• RTK coding agent के terminal output को compress करके लागत घटाने का वादा करता है, लेकिन raw output में कमी का मतलब अपने-आप सस्ता, सुरक्षित और अधिक सटीक software engineering नहीं होता
• “60~90% reduction” का मतलब यह नहीं कि LLM billing उतनी ही घट गई; यह ज़्यादा करीब उस command-line output के प्रतिशत के है जिसे RTK ने हटा दिया
• अगर terminal output चुपचाप खराब हो जाए या कुछ हिस्सा गायब हो जाए, यानी silent failure हो, तो agent महत्वपूर्ण stack trace या compiler context के बिना गलत निर्णय ले सकता है
• सिर्फ token reduction graph काफ़ी नहीं है; यह दिखाने के लिए task success rate और SWE-bench जैसी accuracy evaluation चाहिए कि autonomous agent ने सच में काम पूरा किया या नहीं
• RTK एक स्वतंत्र product से ज़्यादा dev tool feature जैसा लगता है, और git, cargo, npm, grep जैसे CLI output के बदलावों के प्रति संवेदनशील है, इसलिए इसे production agent के critical path में रखना operational risk बढ़ाता है

---

बचत के आंकड़ों के पीछे छिपी असली लागत संरचना

• RTK coding agent के लिए terminal output compression के जरिए token usage reduction और लागत बचत का दावा करता है
  • इसे GitHub पर 60k से ज़्यादा stars मिले हैं, और industry इस प्रचार पर तेज़ी से प्रतिक्रिया दे रही है
  • लेकिन जो dev tool दावे “बहुत अच्छे” लगते हैं, उनकी वास्तविक संरचना को परखना ज़रूरी है
• “60~90% reduction” वाला viral आँकड़ा वास्तविक API billing reduction के बराबर नहीं है
  • RTK असल में Bash output के सिर्फ़ एक हिस्से को कम करता है
  • deep file reading, repository context, system prompt, और model के internal reasoning tokens जैसे बड़े cost factor फिर भी बने रहते हैं
  • rtk gain जैसे command बुनियादी architecture optimization से ज़्यादा social media screenshot या non-technical manager को दिखाने लायक metric पर केंद्रित लगते हैं
  • हाल की GitHub issues में भी बढ़ा-चढ़ाकर पेश किए गए metrics पर सवाल उठने लगे हैं

सटीकता और operational stability ज़्यादा बड़े कारक हैं

• अगर optimization के साथ accuracy न आए तो उसका मतलब कम रह जाता है, और repository की public issues में terminal output के चुपचाप टूटने या गायब होने के मामले पहले से दिख रहे हैं
  • मुख्य जोखिम यह है कि AI agent को पता ही नहीं चलता कि text compress किया गया है
  • अगर RTK कुछ token बचाने के लिए stack trace या compiler context की अहम lines हटा दे, तो user और LLM दोनों अधूरी जानकारी के साथ काम करते हैं
  • RTK अपनाना एक ऐसी बाहरी layer पर निर्भर होने का फैसला है जिसे बहुत सारे CLI tools के output को बिना meaning खोए parse, interpret और summarize करना होगा
• RTK token reduction graph दिखाता है, लेकिन वास्तव में महत्वपूर्ण task success rate metric गायब है
  • असली सवाल यह है कि autonomous agent ने execution loop के अंत में software engineering समस्या हल की या नहीं
  • prompt cost 80% घट जाने पर भी अगर context degrade हो जाए और agent hallucinate करे, build fail करे, या loop में फँस जाए, तो अंत में ज़्यादा tokens खर्च हो सकते हैं
  • cost graph के साथ सख़्त SWE-bench जैसी accuracy evaluation आने तक RTK की कहानी अधूरी है
• architecture के नज़रिए से RTK agent और shell के बीच synchronous critical path में एक नाज़ुक external dependency जोड़ता है
  • output optimization किसी स्वतंत्र product या platform से ज़्यादा एक feature जैसा है
  • अगर प्रमुख CLI और dev tools LLM consumption के लिए native --compact या --json-stream flags देने लगें, तो RTK का मुख्य लाभ खत्म हो सकता है
• RTK इंसानों के पढ़ने लायक stdout/stderr format को खास तौर पर parse करने के तरीके पर बहुत निर्भर है, इसलिए इसे maintain करना कठिन है
  • अगर git, cargo, npm, grep terminal format में कुछ spaces या error layout बदल दें, तो RTK के regex और parsing filters टूट सकते हैं
  • ऐसे में यह स्पष्ट error देने के बजाय चुपचाप fail हो सकता है और agent को खराब या आंशिक text दे सकता है
• RTK raw terminal tokens कम करने जैसे चमकदार metric के बदले deterministic reliability, semantic completeness, और architectural simplicity की कीमत वसूलता है
  • जब तक यह silent degradation को ठीक नहीं करता और transparent task accuracy benchmark नहीं देता, तब तक इसे production agent workflow के critical path में रखना मिलने वाली छूट की तुलना में बड़ा operational risk है

[GN⁺]

Hacker News की राय

• अच्छा लग रहा है कि ऐसे लेख आखिरकार पूरे LLM जादुई डिब्बा इंडस्ट्री को लेकर थोड़ी पकड़ बनाने लगे हैं
  caveman mode से लेकर RTK और semantic search तक, लगता है डेवलपर इंजीनियर कम और मंत्र पढ़ने वाले जादूगर ज़्यादा बन गए हैं, और काम पर तो खासकर थकान होती है क्योंकि हर किसी को यक़ीन होता है कि उसका अपना मंत्र ही टोकन बचाने का अंतिम तरीका है
  मेरा मानदंड यह है: जो आइडिया evaluation harness के अंदर नहीं है, वह आम तौर पर खास नहीं होता, और अच्छे आइडिया आखिरकार Codex/Claude तक पहुँच ही जाते हैं। GitHub पर टोकन के कुछ प्रतिशत बचाने का दावा करने वाली बातें भी भरोसेमंद नहीं लगतीं
  इस क्षेत्र में भ्रामक टूल्स से बचना मुश्किल है, और काश लोग इसे थोड़ा ज़्यादा आलोचनात्मक नज़र से देखना शुरू करें

  • यह पूरी तरह गलत है, और आप यह कम आँक रहे हैं कि अग्रिम पंक्ति की कंपनियाँ LLM मॉडल बनाने के अलावा बाकी क्षेत्रों में कितनी अक्षम हैं
    एक साल तक “game engine की तरह लिखे गए” झिलमिलाते TUI जैसे उदाहरण भी रहे, और मैंने खुद कई benchmarks चलाकर देखा है कि कुछ प्रमाणित तरीके वही परिणाम देते हुए भी टोकन घटाते हैं। उदाहरण के लिए वही CVE ढूँढना, या code review में वही bug पकड़ना
    मेरा छोटा-सा प्रमाण https://maki.sh पर देख सकते हैं
  • इसलिए मैं हर चीज़ का blind A/B test करता हूँ
    इसमें बहुत टोकन जलते हैं, लेकिन यह साबित करना पड़ता है कि उसमें सच में value है, और ज़्यादातर चीज़ें उस कसौटी पर बिल्कुल खरी नहीं उतरतीं
    मेरे AI agent में भी कई features हैं, लेकिन मैं यह नहीं मानता कि 4 महीने पहले के blind A/B test के नतीजे आज भी उतने ही मायने रखते हैं। मेरे शब्द चुनने के तरीके भर से नतीजे बहुत बदल सकते हैं
    फिर भी मैं खुद value की पुष्टि करने और उसे अपनी आँखों से देखने के लिए test करता हूँ। मैं blind A/B test के ठोस नतीजे खास तौर पर सार्वजनिक नहीं करता
    मैंने दूसरों को blind A/B test बहुत खराब तरीके से करते भी देखा है, और अगर measurement कमजोर हो तो test खुद ही बेकार हो जाता है
    हम सब मिलकर यह समस्या सुलझा रहे हैं, और इसमें बहुत-सा black magic है, इसलिए hooks पर काफ़ी निर्भरता है। मेरे छोटे AI agent में भी black magic भरा होगा
    जो एक बात मैं पक्का जानता हूँ, वह बस यह है कि यह मेरे लिए काम करता है। इसे इस्तेमाल किए बिना आजकल लोग AI के साथ काम कैसे करते हैं, यह सच कहूँ तो मुझे नहीं पता
    लिंक छोड़ रहा हूँ, लेकिन इसका मतलब यह नहीं कि मैं जो भी तुम करो उसे recommend कर रहा हूँ। इसे ज़्यादातर दूसरे software engineers ही इस्तेमाल करते हैं, और यह मेरे काम के लिए बहुत विशेष रूप से बना है। ज़्यादा से ज़्यादा इससे तुम्हें खुद implement करने लायक कुछ ideas मिल सकते हैं
    https://github.com/notque/vexjoy-agent
  • “अच्छे आइडिया Codex/Claude तक पहुँच जाते हैं” वाली बात तभी सही है जब कोई RTK जैसे टूल बनाए और दूसरे लोग उन्हें आज़माएँ
    इस दौर को बस किनारे बैठकर देखना भी ठीक है, लेकिन RTK, Headroom, caveman mode जैसे टूल्स प्रोसेस किए जाने वाले input/output tokens घटाते हैं, और local LLM पर मापी जा सकने वाली speed improvements दे सकते हैं
    इससे अंतिम output quality बिगड़ती है या नहीं, यह कहने लायक data अभी काफी नहीं है, लेकिन पता लगाने के लिए इनके साथ हाथ आज़माना मज़ेदार है
  • आइडिया अपने आप में उचित है। अगर context window के signal-to-noise ratio को कम किया जा सके तो यह अच्छी बात है
    बस यह अभी साबित नहीं हुआ है कि RTK वास्तव में ऐसा करता है। “up to 90%” जैसे अर्थहीन वाक्यांशों के बजाय, मैं यह देखना चाहूँगा कि इस टूल से वास्तव में क्या फर्क पड़ता है, इसका ठीक से benchmark किया हुआ परिणाम
  • इससे भी आगे, git status जैसे command के लिए rtk में जो कुछ optimizations मैंने देखे, वे शायद पहले ही model layer तक पहुँच चुके हैं
    Codex अब git status की जगह git status --short जैसे tool calls ज़्यादा करता है

• मैं ही लेखक हूँ। सच कहूँ तो, एक software engineer के रूप में rtk ai मुझे बहुत अजीब लगा, इसलिए मैंने यह लिखा
  star count, accuracy का कोई ज़िक्र न होना, और management द्वारा cost optimization के लिए ऐसी चीज़ों को आगे धकेलने का तरीका मुझे खटका। अब लोग हर संभव command को rtk में wrap कर रहे हैं, सारे प्रमुख commands को संभालने की कोशिश कर रहे हैं, और यहाँ तक तय करना चाहते हैं कि किस तरह का output मिलना चाहिए

  • मैं सच में https://www.github.com/jahala/tilth पर राय सुनना चाहूँगा
    यह RTK से अलग approach है, और benchmarks में प्रति सही उत्तर की लागत को लगभग 40% तक घटाने का दावा करता है
  • समझ नहीं आया कि अपने दावे के समर्थन में वास्तविक usage metrics एक भी क्यों नहीं दिए गए। यह बहुत मददगार नहीं था

• टूल आउटपुट मेरे आउटपुट का बड़ा हिस्सा बनाता है। अगर 39 लाख input tokens में से 37 लाख tokens बचाए जा सकते हैं, तो मैं वह मान लूंगा। बचाए गए tokens, बचाए गए tokens ही होते हैं
  RTK यूज़र के तौर पर अच्छा होता अगर accuracy benchmark होता, लेकिन compression की वजह से मॉडल ने कोई महत्वपूर्ण चीज़ मिस की हो, ऐसा सबूत मैंने अभी तक नहीं देखा
  इसकी design philosophy में accuracy preservation को बहुत सख्ती से लिया जाता है, यहाँ तक कि अगर filter fail हो जाए तो यह original output पर वापस लौट आता है। मैं अक्सर इस्तेमाल होने वाले commands का source भी खुद देख चुका हूँ, वह मुझे पसंद आया, और अब तक इसने मेरा भरोसा जीता है
  यह चिंता भी है कि अगर git, cargo, npm, grep terminal formatting के कुछ spaces बदल दें या error layout बदल दें, तो RTK के regex और parser टूट सकते हैं, लेकिन filter fail होने पर यह original output पर लौट आता है। RTK ऐसा टूल है जिसे इस तरह design किया गया है कि agent को खराब या आंशिक text न खिलाया जाए
  चिंताएँ वाजिब हैं, लेकिन आलोचना सबूत से समर्थित होनी चाहिए। जानना चाहूँगा कि क्या आपने RTK इस्तेमाल किया है, और क्या accuracy preserve न कर पाने का कोई सबूत मिला है

  • इश्यूज़ देखते समय मुझे ये दिखे, और इनमें से कुछ काफ़ी खराब लगते हैं
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • हर बार बचाए गए tokens, सच में बचाए गए tokens नहीं होते
    RTK flags और दूसरी जानकारी हटा देता है। कभी-कभी बाद में वही वापस पाने के लिए और ज़्यादा tokens खर्च करने पड़ते हैं। भले ही उस tool call में 70% tokens बच गए हों, metrics में यह नहीं दिखता कि tool call 1 बार की जगह 3 बार करना पड़ा
    यह भी देखना चाहिए कि हटाए गए output की वजह से reasoning tokens ज़्यादा तो नहीं लग रहे
  • सिर्फ़ यह कहना काफ़ी नहीं कि accuracy बहुत सख्ती से preserve की जाती है
    latest models और पीछे रह गए open weight models के बीच cost difference, या सबसे बड़े model और उसके नीचे वाले model के cost difference को देखते हुए performance को बहुत सावधानी से नापना चाहिए
    यह नहीं कि आलोचक सबूत दें, बल्कि RTK को यह साबित करना चाहिए कि RTK performance खराब नहीं करता

• मुद्दे की जड़ यह है कि AI को बेहतर बनाने का दावा करने वाले टूल अनगिनत हैं, लेकिन AI सच में बेहतर काम कर रहा है या नहीं, इसे मापने का तरीका नहीं है
  लोकप्रिय products वाली बड़ी कंपनियों के पास तरीका होता है। सामान्य product analytics और chatbot evaluation के बीच कहीं वे यह पता लगा लेती हैं कि user session में सफल हो रहा है या नहीं। वही उनका काम है
  लेकिन जो individual developer दिन में 3 से 50 sessions चलाता है, उसके पास यह जानने का लगभग कोई तरीका नहीं कि LLM को क्या बेहतर बनाता है। सब कुछ बस अंदाज़े पर चलता है
  हमारी कंपनी में पूरी stack है: पसंदीदा harness, model, skills, और code structure तक। Claude Code के दस लाखवें हिस्से जितने scale पर भी यह setup हमारे लिए काम कर रहा है या नहीं, इसे मापने का तरीका होना चाहिए

  • मेरे product में हम साफ़ तौर पर agent से पूछने को कहते हैं। ऐसे real examples और real repositories हैं जिन्हें आप खुद आज़मा सकते हैं
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    मुझे average token savings में ज़्यादा दिलचस्पी नहीं है। मेरी ज़्यादा दिलचस्पी इस बात में है कि AI अनावश्यक files को context में ऊपर ला रहा है या नहीं, क्योंकि इससे reasoning प्रभावित हो सकती है
    काम के बाद agent से बस यह पूछ लें: “अगर तुम्हें पहले से file का उद्देश्य पता होता, तो तुम्हारे हिसाब से कितनी files तुम नहीं पढ़ते?”
  • एक valid benchmark बनाना बहुत बड़ा काम है। शायद यह सही बात है, और इसी वजह से यह और झुंझलाहट पैदा करता है
    framework को लेकर ही पहले बहुत बहस थी, और यह उससे भी बुरा है। यह तुम्हारे अंदाज़े बनाम मेरे अंदाज़े की लड़ाई बन जाती है। non-deterministic output हमें यहाँ तक ले आएगा, यह किसने सोचा था
  • जवाब है। ऐसे tools को सिर्फ़ token savings से नहीं, बल्कि cost per correct answer से benchmark करना चाहिए

• मैंने इसे खुद इस्तेमाल किया, और यह उन messages को compress नहीं करता जो मेरे context का 90% बनाते हैं, इसलिए कुल token usage का सिर्फ़ छोटा हिस्सा ही compress हुआ
  अगर आप पोस्ट को ध्यान से पढ़ें तो यह बात साफ़ लिखी है। /context देखने पर शायद पता चलेगा कि tokens tool calls में नहीं, कहीं और खर्च हो रहे हैं। इसलिए सिर्फ़ tool calls को compress करने वाला proxy, चाहे tool calls को 8x compress करने का दावा सही भी हो, बहुत बड़ा असर नहीं डालता
  लंबी coding sessions में यह मेरे लिए खास मायने नहीं रखता था
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• इस पोस्ट में rebuttal को support करने वाला data लगभग नहीं है, और ज़्यादातर यह LLM से जनरेट किए गए लेख जैसा लगता है

• Semble में भी हमें ऐसी शिकायतें मिली हैं। मुझे लगता है शिकायतें वाजिब हैं, लेकिन इस तरह के benchmarks बनाना harness × model × MCP/CLI combination की वजह से बहुत कठिन और महंगा है
  पारंपरिक machine learning या tools में benchmark न दिखाना आम तौर पर red flag माना जाता था। लेकिन LLM tools में, मैं पक्का नहीं हूँ

• अगर agent को RTK compression की जानकारी हो और उसके पास bypass option भी हो, तो truncation detect करवाने का तरीका है। मैं पूरा original text restore करने के लिए RTK_DISABLE=1 इस्तेमाल करता हूँ
  यह अच्छी तरह काम करता है, और हाँ, सही है। क्योंकि सिर्फ़ command output compress होता है, इसलिए “compression” के नज़रिए से यह सिर्फ़ input tokens को प्रभावित करता है

• यह बात सही है कि mainstream CLI और developer tools, LLM consumption के लिए native --compact या --json-stream flags दे सकते हैं, लेकिन वे जल्दी ऐसा नहीं करने वाले
  इसलिए rtk, caveman, ponytail जैसे tools लगातार बढ़ती लागत को कम करने की कोशिश कर रहे हैं। 2,000 लोगों के संगठन में अभी यह लगभग 25 लाख डॉलर के स्तर पर है, और हर कोई इन trade-offs को समझते हुए tuning कर रहा है
  लेखक के दावे के उलट, हम इन trade-offs को अच्छी तरह समझते हैं, और tools को fork करके, benchmark करके, और output quality हमारे use case के हिसाब से ठीक है या नहीं यह verify करके इस्तेमाल कर रहे हैं। हम इन्हें आँख बंद करके नहीं अपना रहे
  individual developer के लिए यह ज़रूरी न भी हो सकता है, और लागत घटाने के लिए किसी दूसरे model को self-host करना बेहतर हो सकता है। लेकिन organizations के लिए यह काफ़ी बड़ा और कठिन मुद्दा है
  अच्छा है कि ऐसी पोस्ट इस पर रोशनी डालती हैं, लेकिन tools की तरह ऐसी पोस्टों को भी कुछ हद तक छानकर पढ़ना चाहिए

• Mac पर rtk gain चलाकर देखा। मुख्य डेवलपमेंट मशीन को memory problems की वजह से फिर से image करना पड़ा था और कुछ चीजें उलझी हुई थीं, इसलिए वहाँ verify नहीं कर पाया, लेकिन Mac पर लगभग इनपुट 51 हज़ार टोकन और output 23 हज़ार token कम हुए, और हर command पर औसतन 3 सेकंड बचे
  समझ नहीं आता कि इसे लेकर इतना गुस्सा क्यों है, और इस पर अलग से पोस्ट लिखने की भी क्या ज़रूरत थी
  पता नहीं कौन stack trace को RTK में pipe करता है। मैं इसे सिर्फ बहुत specific programs में इस्तेमाल करता हूँ, और compiler output ठूँसना बेवकूफी लगता है। Agent को बस यह निर्देश दिया जा सकता है कि RTK सिर्फ कुछ खास command sets पर ही इस्तेमाल करे