Token sıkıştırma yanılsaması: RTK’ye neden şüpheyle yaklaşıyorum

• RTK, kodlama ajanlarının terminal çıktısını sıkıştırarak maliyeti düşürmeyi vaat ediyor, ancak ham çıktının azalması doğrudan daha ucuz, daha güvenli ve daha doğru yazılım mühendisliği anlamına gelmiyor
• “%60~90 tasarruf”, LLM faturasının o kadar azaldığı anlamına gelmiyor; bu oran, RTK’nin kaldırdığı komut satırı çıktısı oranına daha yakın
• Terminal çıktısının sessizce bozulduğu veya eksildiği silent failure durumları oluşursa, ajan önemli stack trace’ler veya derleyici bağlamı olmadan yanlış kararlar verebilir
• Yalnızca token tasarrufu grafikleri yeterli değil; otonom ajanların işi gerçekten tamamlayıp tamamlamadığını gösteren görev başarı oranı ve SWE-bench tarzı doğruluk değerlendirmeleri gerekli
• RTK, bağımsız bir üründen çok bir geliştirme aracı özelliğine benziyor; git, cargo, npm, grep gibi CLI çıktılarındaki değişikliklere karşı kırılgan olduğu için, bunu production ajanlarının kritik yoluna koymanın operasyonel riski yüksek

---

Tasarruf rakamlarının gizlediği gerçek maliyet yapısı

• RTK, kodlama ajanları için terminal çıktısı sıkıştırmasıyla token kullanımında azalma ve maliyet düşüşü vaat ediyor
  • GitHub’da 60k’dan fazla yıldız aldı ve sektör bu tanıtıma güçlü tepki veriyor
  • Ancak “fazla iyi görünen” geliştirme aracı iddialarında gerçek yapıya bakmak gerekir
• Viral olan “%60~90 tasarruf” rakamı, gerçek API fatura düşüşüyle aynı şey değil
  • RTK’nin azalttığı şey, Bash çıktısının yalnızca bir kısmı
  • Derin dosya okuma, depo bağlamı, sistem prompt’ları ve modelin iç muhakeme token’ları gibi daha büyük maliyet kalemleri yerinde duruyor
  • rtk gain gibi komutlar, temel mimari optimizasyondan çok sosyal medya ekran görüntülerine veya teknik olmayan yöneticilere gösterilecek metriklere odaklanmış gibi görünüyor
  • Son GitHub issue’larında da abartılmış metriklerle ilgili sorular yükselmeye başladı

Doğruluk ve operasyonel kararlılık daha büyük değişkenler

• Doğruluk eşlik etmiyorsa optimizasyonun anlamı yok; deponun açık issue’larında terminal çıktısının sessizce bozulduğu veya eksildiği örnekler şimdiden görülüyor
  • Asıl risk, AI ajanının metnin sıkıştırıldığını bilmemesi
  • RTK, birkaç token tasarrufu için stack trace’in veya derleyici bağlamının kritik satırlarını kaldırırsa, hem kullanıcı hem de LLM eksik bilgiyle çalışmak zorunda kalır
  • RTK’yi devreye almak, sayısız CLI aracının çıktısını anlam kaybı olmadan parse edip yorumlayan ve özetleyen harici bir katmana bağımlı olmayı seçmek demek
• RTK, token tasarrufu grafikleri gösteriyor ama gerçekte önemli olan görev başarı oranı metriği eksik
  • Asıl mesele, otonom ajanın çalıştırma döngüsünün sonunda yazılım mühendisliği problemini çözüp çözmediği
  • Prompt maliyetini %80 düşürseniz bile bağlam zayıfladığı için ajan halüsinasyon görebilir, build’i başarısız olabilir veya döngüye girebilir; sonuçta daha fazla token harcanabilir
  • Maliyet grafikleriyle birlikte titiz SWE-bench tarzı doğruluk değerlendirmeleri gelene kadar RTK anlatısı eksik kalıyor
• Mimari açıdan RTK, ajan ile shell arasındaki senkron kritik yol üzerine kırılgan bir harici bağımlılık ekliyor
  • Çıktı optimizasyonu, bağımsız bir ürün veya platformdan çok bir özelliğe benziyor
  • Başlıca CLI ve geliştirme araçları, LLM tüketimine uygun yerel --compact veya --json-stream bayrakları sunarsa RTK’nin temel avantajı ortadan kalkabilir
• RTK, insanlar tarafından okunan stdout/stderr biçimlerini özel olarak parse etmeye büyük ölçüde dayandığı için bakımı zor
  • git, cargo, npm, grep terminal biçiminde birkaç boşluğu veya hata yerleşimini değiştirirse, RTK’nin regex’leri ve parse filtreleri bozulabilir
  • Bu durumda açık bir hata yerine sessizce başarısız olup ajana bozulmuş veya kısmi metin verebilir
• RTK, ham terminal token’larını azaltma gibi gösterişli bir metrik uğruna belirleyici güvenilirlikten, anlamsal bütünlükten ve mimari sadelikten ödün verdiriyor
  • silent degradation sorununu çözene ve şeffaf görev doğruluğu benchmark’ları sunana kadar, bunu production ajan iş akışlarının kritik yoluna koymak, sağladığı indirime kıyasla yüksek operasyonel risk taşıyor

[GN⁺]

Hacker News yorumları

• Bu tür yazıların sonunda genel LLM sihirli kutu endüstrisine karşı biraz güç kazanmaya başlamasına sevindim
  caveman mode'dan RTK'ye, anlamsal aramaya kadar geliştiriciler mühendislerden çok büyü okuyan sihirbazlar gibi hissettiriyor; iş yerinde ise özellikle herkes kendi büyüsünün en nihai token tasarruf yöntemi olduğuna inandığı için yorucu oluyor
  Ölçütüm şu: değerlendirme harness'i içinde olmayan fikirler genelde pek iyi değil ve iyi fikirler de sonunda Codex/Claude'a çıkıyor diye düşünüyorum. GitHub'da token'ların yüzde birkaçını tasarruf ettirdiğini reklam eden şeylere de inanmak zor
  Bu alanda aldatıcı araçlardan kaçınmak zor ve insanların buna daha eleştirel bakmaya başlamasını isterim

  • Buna tamamen katılmıyorum; ön saftaki şirketlerin LLM modeli yapmak dışındaki alanlarda ne kadar beceriksiz olduğunu hafife alıyorsun
    1 yıl boyunca “oyun motoru gibi yazılmış” yanıp sönen TUI örnekleri de oldu ve bizzat çeşitli benchmark'lar çalıştırdığımda aynı sonucu üretirken token'ları azaltan doğrulanmış yöntemler gördüm. Örneğin aynı CVE'yi bulmak ya da code review'da aynı bug'ı yakalamak gibi
    Küçük kanıtım için https://maki.sh adresine bakabilirsin
  • Bu yüzden her şeyi kör A/B testiyle ölçüyorum
    Çok token yakıyorlar ama gerçekten değer ürettiklerini kanıtlamaları gerekiyor ve çoğu bu çıtanın yanına bile yaklaşamıyor
    Benim AI ajanımda da çeşitli özellikler var ama 4 ay önceki kör A/B testinin sonucunun bugün hâlâ anlamlı olduğunu düşünmüyorum. Sadece benim kelime seçimim bile sonucu büyük ölçüde değiştirebilir
    Yine de değeri bizzat doğrulamak ve gözümle görmek için test ediyorum. Belirli kör A/B test sonuçlarını özellikle paylaşmıyorum
    Başkalarının kör A/B testini çok yanlış yaptığını da gördüm; ölçüm kötüyse testin kendisi anlamsız oluyor
    Hepimiz bu sorunu birlikte çözmeye çalışıyoruz ve ortada çok fazla kara büyü olduğu için hooks'a epey bağımlıyız. Benim küçük AI ajanımda da bolca kara büyü vardır muhtemelen
    Kesin bildiğim tek şey, bunun benim için çalıştığı. Bunu kullanmasam insanların şu anda AI ile nasıl çalıştığını açıkçası bilmiyorum
    Link bırakıyorum ama ne yaparsan yap bunu önerdiğim anlamına gelmiyor. Bunu çoğunlukla başka yazılım mühendisleri kullanıyor ve benim yapmam gereken işe çok özel. En fazla, kendin uygulayabileceğin fikirler verebilir
    https://github.com/notque/vexjoy-agent
  • “İyi fikirler Codex/Claude'a çıkar” sözü ancak birileri RTK gibi araçlar yapıp başkaları da bunları denediğinde geçerli olur
    Bu turu sadece izlemek de sorun değil ama RTK, Headroom, caveman mode gibi araçlar işlenmesi gereken giriş/çıkış token'larını azaltıyor ve yerel LLM'lerde ölçülebilir hız artışı sağlayabiliyor
    Nihai çıktı kalitesine zarar verip vermediği konusunda konuşacak kadar veri yok ama bunu anlamak için kurcalamak eğlenceli
  • Fikrin kendisi makul. Bağlam penceresindeki sinyal/gürültü oranını düşürebiliyorsa bu iyi bir şey
    Ama RTK'nin gerçekten bunu yapıp yapmadığı henüz kanıtlanmış değil. “Yüzde 90'a kadar” gibi anlamsız ifadeler yerine, bu aracın pratikte yarattığı farkı düzgün benchmark'layan sonuçları görmek isterim
  • Daha da ötesi, git status gibi komutlar için rtk'de gördüğüm bazı optimizasyonlar zaten model katmanına çıkmış gibi görünüyor
    Codex artık git status yerine sık sık git status --short gibi tool call'lar yapıyor

• Yazar benim. Açık konuşmak gerekirse bunu, bir yazılım mühendisi olarak rtk ai bana çok tuhaf göründüğü için yazdım
  Yıldız sayıları, doğrulukla ilgili herhangi bir değerin olmaması ve yöneticilerin maliyet optimizasyonu için buna yüklenme biçimi beni rahatsız etti. Artık insanlar mümkün olan her komutu rtk ile sarmalıyor, tüm ana komutları ele almaya çalışıyor ve hatta hangi çıktının alınması gerektiğini bile belirlemeye kalkıyor

  • https://www.github.com/jahala/tilth hakkında samimi görüşlerini duymak isterim
    RTK'den farklı bir yaklaşım ve doğru cevap başına maliyeti yaklaşık %40 azaltacak şekilde benchmark edildi
  • İddiaları destekleyecek gerçek kullanım rakamları neden hiç paylaşılmamış, anlayamadım. Pek yardımcı olmadı

• Araç çıktısı, çıktımın büyük bir kısmını oluşturuyor. 3,9 milyon giriş token’ının 3,7 milyonunu kurtarabiliyorsam bunu kabul ederim. Tasarruf edilen token, tasarruf edilen tokendır
  Bir RTK kullanıcısı olarak doğruluk benchmark’larının olmasını isterim, ama sıkıştırma yüzünden modelin önemli bir şeyi kaçırdığına dair henüz bir kanıt görmedim
  Tasarım felsefesi gereği doğruluğun korunması çok katı ele alınıyor ve filtre başarısız olursa ham çıktıya geri dönülüyor. Sık kullandığım komutların kaynaklarına da bizzat baktım; hoşuma gitti ve şimdiye kadar güven kazandığını düşünüyorum
  git, cargo, npm, grep terminal biçimlendirmesinde birkaç boşluğu değiştirirse ya da hata düzenini değiştirirse RTK’nin regex’lerinin ve parser’larının bozulacağı yönünde kaygılar var, ama filtre başarısız olursa yine ham çıktıya dönülüyor. RTK, bozuk veya kısmi metni ajana vermemek üzerine tasarlanmış bir araç
  Kaygılar geçerli, ama eleştirilerin kanıtla desteklenmesini isterim. RTK’yi kullanıp kullanmadıklarını ve doğruluğu koruyamadığına dair kanıt bulup bulmadıklarını merak ediyorum

  • Konuyu incelerken buna rastladım; göze çarpan birkaç issue oldukça kötü görünüyor
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • Tasarruf edilen token, tasarruf edilen token değildir denebilecek durumlar da var
    RTK bayrakları ve başka bilgileri kaldırıyor. Bazen bunları sonradan geri kazanmak için daha fazla token harcamak gerekiyor. O araç çağrısında token’ların %70’ini kurtarmış olsanız bile, metrikler araç çağrısını 1 kez yerine 3 kez yapıp yapmadığınızı göstermiyor
    Kaldırılan çıktı yüzünden daha fazla çıkarım token’ı harcanıp harcanmadığına da bakmak gerekir
  • Doğruluğu çok katı biçimde koruyor olması tek başına yeterli değil diye düşünüyorum
    En yeni model ile geride kalmış açık ağırlıklı modeller arasındaki maliyet farkını, ya da en büyük model ile bir altındaki model arasındaki maliyet farkını düşününce performansın çok dikkatli ölçülmesi gerekiyor
    Kanıt sunma yükü eleştiren tarafta olmaktan ziyade, RTK’nin performansı düşürmediğini RTK’nin kanıtlaması gerekir

• Mesele şu ki, AI’yı daha iyi yaptığını söyleyen sayısız araç var ama AI’nın gerçekten daha iyi çalışıp çalışmadığını ölçmenin bir yolu yok
  Popüler ürünü olan büyük şirketlerin bir yöntemi var. Genel ürün analitiği ile chatbot değerlendirmesi arasında bir yerde, kullanıcının oturum içinde başarıya ulaşıp ulaşmadığını anlıyorlar. İşleri bu
  Ama günde 3 ila 50 oturum çalıştıran bireysel geliştiricilerin, neyin LLM’i daha iyi yaptığını bilmesinin neredeyse hiçbir yolu yok. Her şey sezgiye kalıyor
  Şirketimizde tercih edilen harness, model, skills ve hatta kod yapısına kadar uzanan tam bir stack var. Claude Code’un milyonda biri ölçekte bile bu kurulumun bize yarayıp yaramadığını ölçmenin bir yolu olmalı

  • Benim ürünümde, ajana bunu açıkça sormasını söylüyoruz. Deneyebileceğiniz gerçek örnekler ve gerçek depolar var
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    Ortalama token tasarrufuyla pek ilgilenmiyorum. Daha çok AI’nın gereksiz dosyaları bağlama taşıyıp taşımadığıyla ilgileniyorum; çünkü bu, çıkarımı etkileyebilir
    Görevden sonra ajana “dosyanın amacını baştan bilseydin, okumazdım diyeceğin kaç dosya var sence?” diye sormanız yeterli
  • Geçerli bir benchmark oluşturma çabası muazzam. Muhtemelen doğru bir nokta bu ve bu yüzden daha da sinir bozucu
    Zaten framework’ler üzerinde bolca tartışma vardı; bu çok daha kötü. Senin sezgin benim sezgime karşı durumuna dönüyor. Deterministik olmayan çıktının bizi buraya getireceğini kim tahmin ederdi ki
  • Cevap var. Bu tür araçlar basit token tasarrufu ile değil, doğru cevap başına maliyet üzerinden benchmark edilmelidir

• Bizzat denedim; bağlamımın %90’ını oluşturan mesajları sıkıştırmadığı için toplam token kullanımının yalnızca küçük bir kısmını sıkıştırdı
  Yazıyı dikkatle okursanız zaten açıkça böyle deniyor. /context çıktısına bakarsanız, muhtemelen token tüketiminin araç çağrılarında olmadığını görürsünüz. Bu yüzden yalnızca araç çağrılarını sıkıştıran bir proxy, araç çağrılarını 8 kat sıkıştırdığı doğru olsa bile büyük bir etki yaratmıyor
  Uzun kodlama oturumlarında benim için pek önemli değildi
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Bu yazı, karşı argümanı destekleyen çok az veri içeriyor ve büyük ölçüde LLM tarafından üretilmiş bir metin gibi okunuyor

• Semble’de de buna benzer şikayetler aldık. Bunun geçerli bir şikayet olduğunu düşünüyorum, ama bu tür benchmark’lar oluşturmak harness × model × MCP/CLI kombinasyonu yüzünden çok zor ve pahalı
  Geleneksel makine öğreniminde ya da araçlarda benchmark göstermemek genelde kırmızı bayraktı. Ama LLM araçlarında durumdan emin değilim

• Ajanın RTK sıkıştırmasının farkında olmasını ve bir baypas seçeneğine sahip olmasını sağlarsanız, kesilmeyi algılamasını sağlamanın bir yolu var. Ben tam ham metni geri yükleyen RTK_DISABLE=1 kullanıyorum
  İyi çalışıyor ve evet, doğru. Yalnızca komut çıktısını sıkıştırdığı için “sıkıştırma” açısından sadece giriş token’larını etkiliyor

• Ana akım CLI ve geliştirici araçlarının, LLM tüketimi için yerel --compact ya da --json-stream bayrakları sunabileceği doğru, ama bunu yakında yapmayacaklar
  Bu yüzden rtk, caveman, ponytail gibi araçlar, durmadan büyüyen maliyetleri azaltmaya çalışıyor. 2.000 kişilik bir organizasyonda bu bugün yaklaşık 2,5 milyon dolar seviyesinde ve herkes bu ödünleşimleri bilip ona göre ayar yapıyor
  Yazarın iddiasının aksine, biz bu ödünleşimlerin gayet farkındayız; araçları fork’layıp benchmark ediyor, çıktı kalitesinin ihtiyaçlarımıza uyduğunu doğrulayarak kullanıyoruz. Körü körüne kullanmıyoruz
  Bireysel geliştiriciler için şart olmayabilir ve maliyet düşürmek adına başka modelleri self-host etmek daha mantıklı olabilir. Ama organizasyonlarda bu oldukça can yakıcı bir kalem
  Böyle yazıların ışık tutması iyi, ama araçlara yaklaştığımız gibi bu tür yazıları da bir miktar süzerek okumak gerekir

• Mac'te rtk gain komutunu denedim. Ana geliştirme makinem bellek sorunları yüzünden yeniden imajlandı ve birkaç şey karıştığı için kontrol edemedim ama Mac'te yaklaşık olarak girdi 51 bin tokenı ve çıktı 23 bin tokenı azalttı, komut başına da ortalama 3 saniye kazandırdı
  Neden bu kadar öfkelendiğini, neden özellikle bunun için yazı bile yazdığını pek anlamıyorum
  Birinin stack trace'i RTK'ye pipe ettiğini sanmıyorum. Ben bunu yalnızca çok belirli programlarda kullanıyorum ve derleyici çıktısını buna doldurmak aptalca görünüyor. Ajana RTK'yi yalnızca belirli bir komut kümesi için kullanmasını söyleyebilirsiniz