Ilusi Kompresi Token: Mengapa Saya Skeptis terhadap RTK

• RTK berjanji menurunkan biaya dengan mengompresi output terminal untuk coding agent, tetapi pengurangan output mentah tidak serta-merta berarti rekayasa perangkat lunak yang lebih murah, aman, dan akurat
• “Penghematan 60~90%” tidak berarti tagihan LLM berkurang sebesar itu, melainkan lebih dekat ke proporsi output command line yang dihapus RTK
• Jika terjadi silent failure di mana output terminal rusak atau hilang tanpa disadari, agen bisa mengambil keputusan yang salah tanpa stack trace penting atau konteks compiler
• Grafik penghematan token saja tidak cukup; diperlukan tingkat keberhasilan tugas dan evaluasi akurasi bergaya SWE-bench yang menunjukkan apakah agen otonom benar-benar menyelesaikan pekerjaan nyata
• RTK tampak lebih mirip fitur alat pengembang daripada produk independen, dan rentan terhadap perubahan output CLI seperti git, cargo, npm, grep, sehingga risiko operasionalnya besar bila ditempatkan di jalur kritis agen produksi

---

Struktur biaya nyata yang tertutupi oleh angka penghematan

• RTK mengusung pengurangan penggunaan token dan biaya lewat kompresi output terminal untuk coding agent
  • Proyek ini telah meraih lebih dari 60k GitHub stars, dan industri tampak sangat merespons promosi ini
  • Namun, klaim alat pengembang yang “terlalu bagus untuk menjadi kenyataan” perlu ditinjau berdasarkan struktur nyatanya
• Angka viral “penghematan 60~90%” tidak sama dengan pengurangan tagihan API yang sebenarnya
  • Yang dikurangi RTK hanyalah sebagian dari output Bash
  • Faktor biaya yang lebih besar seperti pembacaan file mendalam, konteks repositori, system prompt, dan token penalaran internal model tetap ada
  • Perintah seperti rtk gain tampak lebih disesuaikan untuk metrik yang bagus ditampilkan di tangkapan layar media sosial atau kepada manajer nonteknis daripada untuk optimasi arsitektur yang mendasar
  • Isu di GitHub baru-baru ini juga mulai menyoroti metrik yang dibesar-besarkan

Akurasi dan stabilitas operasional adalah variabel yang lebih besar

• Optimasi tidak berarti jika akurasinya tidak ikut terjaga, dan isu publik di repositori sudah menunjukkan kasus di mana output terminal rusak atau hilang secara diam-diam
  • Risiko utamanya adalah agen AI tidak mengetahui bahwa teks telah dikompresi
  • Jika RTK menghapus baris-baris penting dari stack trace atau konteks compiler demi menghemat beberapa token, pengguna dan LLM sama-sama bekerja dengan informasi yang tidak lengkap
  • Mengadopsi RTK berarti bergantung pada lapisan eksternal yang harus mem-parsing, menafsirkan, dan meringkas output dari banyak alat CLI tanpa kehilangan makna
• RTK memang menampilkan grafik penghematan token, tetapi metrik yang benar-benar penting, yaitu tingkat keberhasilan tugas, justru tidak ada
  • Yang penting adalah apakah agen otonom benar-benar menyelesaikan masalah rekayasa perangkat lunak pada akhir execution loop
  • Bahkan jika biaya prompt turun 80%, bila penurunan konteks membuat agen berhalusinasi, gagal build, atau terjebak dalam loop, total token yang dipakai justru bisa bertambah
  • Sampai ada evaluasi akurasi bergaya SWE-bench yang ketat berdampingan dengan grafik biaya, narasi RTK masih belum lengkap
• Dari sudut pandang arsitektur, RTK menambahkan ketergantungan eksternal yang rapuh pada jalur kritis sinkron antara agen dan shell
  • Optimasi output lebih menyerupai fitur daripada produk atau platform yang berdiri sendiri
  • Jika CLI utama dan alat pengembang menyediakan flag native --compact atau --json-stream yang disesuaikan untuk konsumsi LLM, keunggulan utama RTK bisa lenyap
• RTK sangat bergantung pada parsing spesifik terhadap format stdout/stderr yang dibaca manusia, sehingga sulit dipelihara
  • Jika git, cargo, npm, atau grep mengubah beberapa spasi dalam format terminal atau tata letak error, regex dan filter parsing RTK bisa rusak
  • Dalam kasus seperti itu, alih-alih memunculkan error eksplisit, sistem bisa gagal secara diam-diam dan menyuplai teks yang rusak atau parsial ke agen
• RTK menukar keandalan deterministik, kelengkapan semantik, dan kesederhanaan arsitektur demi metrik mencolok berupa penurunan token terminal mentah
  • Sebelum silent degradation diatasi dan benchmark akurasi tugas yang transparan disediakan, menempatkannya di jalur kritis workflow agen produksi membawa risiko operasional yang besar dibanding besarnya diskon yang dijanjikan

[GN⁺]

Komentar Hacker News

• Senang rasanya tulisan seperti ini akhirnya mulai mendapat daya ungkit terhadap keseluruhan industri kotak ajaib LLM
  Dari caveman mode sampai RTK dan pencarian semantik, rasanya para developer sudah jadi penyihir yang melafalkan mantra ketimbang engineer, dan di tempat kerja khususnya melelahkan karena masing-masing yakin mantranya sendiri adalah cara penghematan token yang paling ampuh
  Standar saya begini: ide yang tidak ada di dalam evaluation harness biasanya kurang bagus, dan ide yang bagus pada akhirnya akan naik ke Codex/Claude. Klaim di GitHub yang mengiklankan penghematan token beberapa persen juga sulit dipercaya
  Sulit menghindari alat-alat yang terkesan menipu di bidang seperti ini, dan saya berharap orang-orang mulai melihatnya dengan lebih kritis

  • Itu sepenuhnya salah, dan Anda meremehkan betapa tidak becusnya para perusahaan terdepan di area selain membuat model LLM
    Selama setahun ada juga contoh seperti TUI berkedip yang “ditulis seperti game engine”, dan setelah saya sendiri menjalankan berbagai benchmark, memang ada metode yang terbukti bisa mengurangi token sambil tetap menghasilkan hasil yang sama. Misalnya menemukan CVE yang sama, atau menemukan bug yang sama dalam code review
    Sebagai bukti kecil saya, lihat https://maki.sh
  • Karena itu saya melakukan blind A/B test untuk semuanya
    Memang membakar banyak token, tetapi kita harus membuktikan bahwa itu benar-benar bernilai, dan kebanyakan sama sekali tidak memenuhi standar itu
    Di AI agent saya juga ada berbagai fitur, tetapi saya tidak menganggap hasil blind A/B test dari 4 bulan lalu masih otomatis relevan hari ini. Pilihan kata yang saya gunakan saja bisa sangat mengubah hasilnya
    Meski begitu, saya tetap menguji untuk memastikan nilainya secara langsung dan melihatnya dengan mata kepala sendiri. Hasil blind A/B test yang spesifik sengaja tidak saya publikasikan
    Saya juga pernah melihat orang lain melakukan blind A/B test dengan sangat keliru, dan kalau pengukurannya buruk, pengujiannya sendiri jadi tidak berarti
    Kita semua sedang memecahkan masalah ini bersama-sama, dan karena banyak black magic, kami sangat bergantung pada hooks. Di AI agent kecil saya pun pasti ada banyak black magic
    Satu-satunya hal yang saya tahu pasti adalah: ini bekerja untuk saya. Kalau saya tidak memakai ini, saya jujur tidak tahu bagaimana orang-orang sekarang bekerja dengan AI
    Saya tinggalkan tautannya, tapi itu bukan berarti saya merekomendasikan apa pun yang Anda lakukan. Yang memakainya kebanyakan hanya software engineer lain, dan ini sangat terspesialisasi untuk pekerjaan yang harus saya lakukan. Paling bagus, mungkin bisa memberi ide untuk Anda implementasikan sendiri
    https://github.com/notque/vexjoy-agent
  • Kalimat “ide yang bagus akan naik ke Codex/Claude” hanya berlaku jika ada orang yang membuat alat seperti RTK lalu orang lain mencobanya
    Tidak apa-apa kalau ingin hanya menonton putaran ini, tetapi alat seperti RTK, Headroom, dan caveman mode bisa mengurangi token input/output yang perlu diproses, dan pada LLM lokal bisa menghasilkan peningkatan kecepatan yang terukur
    Soal apakah itu merusak kualitas output akhir, belum ada data yang cukup untuk bicara banyak, tetapi menyentuh dan mencobanya untuk mencari tahu itu menyenangkan
  • Idenya sendiri masuk akal. Kalau bisa menurunkan rasio signal-to-noise pada context window, itu hal yang bagus
    Hanya saja, apakah RTK benar-benar melakukan itu masih belum terbukti. Saya ingin melihat hasil benchmark yang benar-benar mengukur perbedaan yang dihasilkan alat ini, bukan frasa tak bermakna seperti “hingga 90%”
  • Lebih jauh lagi, beberapa optimasi yang saya lihat di rtk untuk perintah seperti git status tampaknya sudah naik ke lapisan model
    Codex sekarang sering melakukan tool call seperti git status --short alih-alih git status

• Saya penulisnya. Sejujurnya, saya menulis ini karena sebagai software engineer, rtk ai terlihat sangat aneh
  Tidak adanya angka, tidak ada pembahasan akurasi, dan cara manajemen mendorong hal seperti ini demi optimasi biaya terasa mengganjal. Sekarang orang-orang membungkus semua perintah yang memungkinkan dengan rtk, mencoba menangani semua perintah utama, bahkan berusaha menentukan output seperti apa yang seharusnya diterima

  • Saya benar-benar ingin mendengar pendapat tentang https://www.github.com/jahala/tilth
    Ini pendekatan yang berbeda dari RTK, dan dibenchmark menurunkan biaya per jawaban benar sekitar 40%
  • Saya tidak mengerti kenapa tidak ada satu pun angka penggunaan nyata yang diajukan untuk mendukung klaimnya. Tidak terlalu membantu

• Output alat mengambil porsi besar dari output saya. Jika dari 3,9 juta token input bisa menghemat 3,7 juta token, saya akan ambil. Token yang dihemat tetaplah token yang dihemat
  Sebagai pengguna RTK, saya ingin ada benchmark akurasi, tetapi sejauh ini saya belum melihat bukti bahwa model melewatkan hal penting karena kompresi
  Dari filosofi desainnya, pelestarian akurasi ditangani dengan sangat ketat, sampai jika filter gagal maka akan kembali ke output asli. Saya juga sudah melihat langsung source dari beberapa perintah yang sering dipakai, saya suka, dan menurut saya sejauh ini sudah mendapat kepercayaan
  Ada kekhawatiran bahwa jika git, cargo, npm, grep mengubah beberapa spasi pada format terminal atau mengubah layout error, regex dan parser RTK akan rusak, tetapi jika filter gagal maka akan kembali ke output asli. RTK adalah alat yang dirancang agar tidak memberi agen teks yang rusak atau parsial
  Kekhawatiran itu valid, tetapi saya ingin kritik didukung bukti. Saya penasaran apakah mereka benar-benar sudah memakai RTK, dan apakah mereka menemukan bukti bahwa RTK gagal menjaga akurasi

  • Saya melihatnya saat menyelidiki issue ini, dan beberapa issue yang menonjol tampak cukup buruk
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • Kadang token yang dihemat bukan benar-benar token yang dihemat
    RTK menghapus flag dan informasi lain. Kadang itu membuat kita menghabiskan lebih banyak token untuk mendapatkannya kembali nanti. Walaupun pada panggilan tool itu tokennya berkurang 70%, metriknya tidak menunjukkan apakah panggilan tool dilakukan 3 kali alih-alih 1 kali
    Perlu juga dihitung apakah output yang dihilangkan membuat kita menghabiskan lebih banyak token penalaran
  • Menurut saya, hanya mengatakan bahwa akurasi dijaga dengan sangat ketat itu tidak cukup
    Jika mempertimbangkan perbedaan biaya antara model terbaru dan model open-weight yang tertinggal, atau perbedaan biaya antara model terbesar dan model satu tingkat di bawahnya, performa harus diukur dengan sangat hati-hati
    Bukan pihak pengkritik yang harus membawa bukti, melainkan RTK harus membuktikan bahwa RTK tidak menurunkan performa

• Intinya, ada tak terhitung banyaknya alat yang mengklaim membuat AI lebih baik, tetapi tidak ada cara untuk mengukur apakah AI benar-benar bekerja lebih baik
  Perusahaan besar dengan produk populer punya caranya. Di suatu titik antara analitik produk umum dan evaluasi chatbot, mereka tahu apakah pengguna berhasil dalam sebuah sesi. Itu pekerjaan mereka
  Tetapi pengembang individu yang menjalankan 3 sampai 50 sesi per hari hampir tidak punya cara untuk tahu apa yang benar-benar membuat LLM lebih baik. Semuanya berdasarkan feeling
  Di perusahaan kami, ada seluruh stack, sampai harness, model, skills, dan struktur kode yang kami sukai. Harus ada cara untuk mengukur apakah setup ini bekerja untuk kami, bahkan pada skala sepersejuta dari Claude Code

  • Di produk saya, kami secara eksplisit menyuruh orang bertanya kepada agen. Ada contoh nyata dan repositori nyata yang bisa dicoba langsung
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    Saya tidak terlalu peduli pada rata-rata penghematan token. Yang lebih saya pedulikan adalah apakah AI tidak memasukkan file yang tidak perlu ke konteks, karena itu bisa memengaruhi penalaran
    Setelah tugas selesai, cukup tanya agen, “kalau sejak awal tahu tujuan file ini, menurutmu ada berapa file yang tidak akan kamu baca?”
  • Upaya membuat benchmark yang valid itu sangat besar. Mungkin itu benar, dan justru itu yang membuatnya lebih menjengkelkan
    Dengan framework yang sudah ada saja orang sudah banyak berdebat, dan ini jauh lebih parah. Jadinya pertarungan feeling saya lawan feeling kamu. Siapa sangka output non-deterministik akan membawa kita sampai sini
  • Jawabannya ada. Alat-alat seperti ini seharusnya di-benchmark bukan berdasarkan sekadar penghematan token, melainkan berdasarkan biaya per jawaban benar

• Saya sudah mencobanya sendiri, dan karena pesan yang mengambil 90% konteks saya tidak dikompresi, yang dikompresi hanya sebagian kecil dari total penggunaan token
  Kalau membaca tulisannya dengan cermat, memang tertulis begitu. Jika melihat /context, Anda mungkin akan sadar bahwa yang menghabiskan token bukan panggilan tool. Jadi proxy yang hanya mengompresi panggilan tool tidak akan berdampak besar, sekalipun klaim bahwa panggilan tool dikompresi 8x itu benar
  Dalam sesi coding yang panjang, itu tidak terlalu penting bagi saya
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Tulisan ini hampir tidak punya data yang mendukung sanggahan tersebut, dan sebagian besar terasa seperti tulisan yang dihasilkan LLM

• Di Semble kami juga pernah menerima keluhan seperti ini. Menurut saya ini keluhan yang valid, tetapi membuat benchmark jenis ini sangat sulit dan mahal karena kombinasi harness × model × MCP/CLI
  Dalam machine learning tradisional atau tool biasa, tidak menunjukkan benchmark biasanya adalah tanda bahaya. Tetapi untuk tool LLM, saya tidak yakin

• Jika agen dibuat sadar akan kompresi RTK dan diberi opsi bypass, ada cara untuk membuatnya mendeteksi pemotongan. Saya memakai RTK_DISABLE=1 untuk memulihkan teks asli secara penuh
  Itu bekerja baik, dan benar. Karena yang dikompresi hanya output perintah, dari sudut pandang “kompresi”, yang terpengaruh hanyalah token input

• Benar bahwa CLI dan developer tool arus utama bisa menyediakan flag native seperti --compact atau --json-stream yang disesuaikan untuk konsumsi LLM, tetapi mereka tidak akan segera melakukannya
  Itulah sebabnya alat seperti rtk, caveman, dan ponytail mencoba mengurangi biaya yang terus membesar. Untuk organisasi berukuran 2.000 orang, biayanya saat ini sekitar 2,5 juta dolar, dan semua orang sedang menyadari serta menyesuaikan trade-off ini
  Bertentangan dengan klaim penulis, kami sangat sadar akan trade-off itu, dan kami menggunakannya sambil mem-fork tool, menjalankan benchmark, dan memverifikasi apakah kualitas output sesuai kebutuhan kami. Bukan memakainya secara membabi buta
  Bagi pengembang individu, ini mungkin tidak terlalu diperlukan, dan mungkin lebih baik self-host model lain untuk menghemat biaya. Tetapi bagi organisasi, ini cukup menyakitkan
  Bagus jika tulisan seperti ini menyorotinya, tetapi seperti halnya tool, tulisan seperti ini juga perlu dibaca dengan sedikit penyaringan

• Di Mac saya sempat menjalankan rtk gain. Mesin pengembangan utama saya sempat di-image ulang karena masalah memori dan ada beberapa hal yang jadi berantakan sehingga saya belum bisa memastikannya, tetapi di Mac ini kira-kira mengurangi 51 ribu token input dan 23 ribu token output, serta menghemat rata-rata 3 detik per perintah
  Saya tidak begitu paham kenapa orang sampai semarah itu, atau kenapa sampai perlu menulis artikel tentang ini
  Saya juga tidak tahu siapa yang menyalurkan stack trace ke RTK. Saya hanya memakainya untuk program yang sangat spesifik, dan memasukkan output compiler ke sana terlihat bodoh. Tinggal instruksikan agen untuk memakai RTK hanya pada kumpulan perintah tertentu saja