Token israfının görünmemesinin nedeni başarısızlık değil, tekrar olmasıdır: aynı dosyayı iki kez okumak, aynı argümanla yeniden denemek, aynı aracı yeniden çağırmak. Bu yüzden bitmiş trace'leri okuyup hangi adımın zaten yapılmış işi tekrar yaptığını işaretleyen bir CLI yaptım!
[Deneyin]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Üyelik gerektirmeden yerelde çalışır. torch indirmez, bu yüzden kurulum birkaç saniyede biter. Python 3.12 ve üzeri gerekir. Claude Code oturum dosyaları ~/.claude/projects/ altında bulunur.
258 turluk açık bir Claude Code oturumunda gerçek çıktı şöyleydi:
Result: WASTE DETECTED
- category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified
1. requery — Read on .../boot.ts
- turns: turn 50 → re-run at turn 58 (of 258 total)
- state: No modification of this file in between — re-read output is unchanged.
- re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
- estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
[Nasıl karar veriyor]
Langfuse veya Phoenix gibi trace'leri depolayıp görselleştirmez. Zaten bitmiş trace'leri okuyup yalnızca israfı işaretler.
İki aşamalıdır. Önce aynı aracı aynı argümanlarla çağıranları gruplayıp, ardından çıktının sha256 değerinin tamamen aynı olup olmadığına bakar. Çıktı farklıysa durum değişmiştir, bu yüzden yakalamaz.
LLM tabanlı değerlendirme yoktur. Aynı trace verilirse her zaman aynı sonuç çıkar.
Bulunan israf dört türe ayrılır. Hata tekrarı (aynı hatayı, nedeni düzeltilmeden yeniden denemek), yan etkili yeniden çalıştırma (durumu değiştiren bir aracı aynı argümanlarla yeniden çağırmak), gri bölge (salt okunur tekrar — yan etki yoktur ama token harcanır), sınıflandırılamayan. Bash veya PowerShell gibi etkisi argüman içeriğine göre tamamen değişebilen araçlar, yalnızca adına bakılarak değerlendirilmez ve sınıflandırılamayan olarak bırakılır.
[Açık veride ne buldu]
Toolathlon benchmark'ında (22 frontier model × 3 çalıştırma, 6.780 trace, 176.270 tool span) doğrudan çalıştırdığımda 8.042 yinelenen çağrı bulundu.
Bu sayıyı olduğu gibi kullanmak şişirme olur. %47'si gri bölgeydi (işin tamamlandığını tekrar ilan etmek, zaten var olan dizini yeniden oluşturmak gibi), bunları çıkarınca 4.251 kalıyor. tool span'e oranı %2,41.
En dikkat çekici olan, durumu değiştiren araçların 1.343 kez yinelenen çalıştırılmasıydı; bunların içinde aynı argümanlarla tekrarlanan e-posta gönderimi 459 kezdi. Ancak bu, yalnızca "aynı araç aynı argümanlarla iki kez çağrıldı" tespitidir; gerçekten iki e-posta gidip gitmediği sadece trace'lere bakarak doğrulanamaz.
[Şaşırtıcı olan]
Claude Code'un kendisi beklediğimden daha verimliydi. Dosyayı yeniden okuma, anlamsız yeniden deneme gibi aday kalıpları altı kez ölçtüm; bunların beşi CC'nin gerçek oturumlarında fiilen yoktu. Önbellekleme ve bağlamı koruma zaten bunu engelliyormuş.
İsrafın daha yoğun olduğu taraf, birden fazla MCP sunucusunun bağlandığı ortamlardı. 20 araçlı CC (%0,80) ile 523 araçlı Toolathlon (%2,41) arasında 3 kat fark vardı.
[Sınırlamalar]
Henüz ölçülmüş bir tasarruf örneği yok. Tespit edip tahmin edebiliyorum, ancak birinin bunu görüp bir şeyleri düzelttikten sonra faturanın gerçekten düştüğünü gösteren veri sayısı 0.
Gri bölgenin %47'si elenmeden, yalnızca sınıflandırılarak gösteriliyor. Salt okunur tekrarların gerçekten israf olup olmadığı yürütme bağlamına göre değişir ve bu benim karar verebileceğim bir şey değil.
Cursor ve Codex henüz desteklenmiyor.
Doğrulamayı geçemeyen dedektörleri kaldırıyorum. Dosyayı yeniden okuma dedektörü yapmıştım, ancak 30 örneklik bir örneklemde precision %70 eşiğinin çok altında kaldığı için (iyimser bakınca bile %3,3, katı bakınca %0) iptal ettim; ön kayıt belgesinde tahminleri ve sonuçları birlikte bıraktım.
[Son olarak...]
Bu alanda araştırma ve doğrulamaya devam etmeyi planlıyorum!
README'nin İngilizce olması için özür dilerim..
Kullanırsanız, şu kısımlar iyileşse iyi olurdu ya da şu özellikler eklense iyi olurdu diyebileceğiniz geri bildirimleri duymak isterim!
Bundan sonra da clew'e ilgi göstermenizi rica ediyorum, teşekkür ederim...!!
1 yorum
[Okuması zor olabilir diye README’nin Türkçe çevirisini ekledim!]
Clew
Ajan izlerinde boşa harcanan işleri bulan deterministik bir dedektör.
Clew, tamamlanmış yapay zeka ajanı çalıştırma izlerini okuyarak, zaten yapılmış işleri tekrarlayan adımları — aynı aracı aynı argümanlarla yeniden çağırma, başarısız bir çağrıyı aynı argümanlarla yeniden deneme, zaten bağlamda bulunan bilgiyi tekrar sorgulama — bulur. LLM kararı olmadan çalıştığı için, aynı izi verdiğinizde her zaman aynı sonucu üretir.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Herkese açık bir Claude Code oturumunda çalıştırılmış gerçek çıktı örneği:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsBu neden önemli?
Yapay zeka kodlama ajanı oturumlarında israf yalnızca faturada ortaya çıkar. Tüm araç çağrıları 200 döndürdüğü ve hiçbir şey hata vermediği için israf gözle görülmez. Ancak izlerin içinde ajan aynı dosyayı iki kez okur, başarısız bir çağrıyı aynı argümanlarla yeniden dener, aynı aracı aynı payload ile tekrar çağırır.
Kodlama ajanı oturumlarında okuma (read) işlemleri token’ların %65~90’ını oluşturduğu için bu tür israf fark edilmeden birikir. Gözlemlenebilirlik araçları izleri gösterir, ancak hangi adımın tekrar olduğunu söylemez.
Neyi tespit eder?
Clew üç tür tekrar kalıbını bulur:
repeat — aynı araç/düğüm tekrar tekrar çağrılır
requery — aynı araç aynı girdiyle yeniden çağrılır (çıktı aynı)
pingpong — iki ajan özünde aynı içeriği birbirine gönderip alır (çoklu ajan)
Her bulgu dört sınıfa ayrılır:
error_repeat — çıktı hata olduğu halde aynı çağrının tekrarlanması
side_effect — durumu değiştiren bir aracın (gönderme/yazma/oluşturma vb.) yeniden çalıştırılması
idempotent — salt okunur/deklaratif bir aracın tekrarlanması (yan etki yok, token tüketir)
unclassified — eşlemede bulunmayan araç. Etki payload’a bağlı olduğu için yalnızca araç adından çıkarım yapılmaz (Bash/PowerShell vb.)
[Nasıl çalışır]
2 aşamalı bir kaskattır:
Yapısal kapı — aynı aracı aynı (normalleştirilmiş) argümanlarla çağıranları gruplar
Özdeşlik kapısı — çıktının sha256 değerinin tamamen aynı olup olmadığını kontrol eder. Farklıysa durum değişmiş demektir, bu yüzden işaretlenmez
Ucuz yapısal kontrol önce adayları eler; pahalı anlamsal kontrol (embedding+cosine) yalnızca gerektiğinde çalışır. LLM kararı olmadığı için sonuç deterministiktir — CI’a koymak istiyorsanız bu önemlidir.
[Girdi biçimi]
Claude Code — oturum JSONL dosyasını doğrudan analiz eder
LangGraph — izlerde zincir tekrarlarını tespit eder
LangChain·CrewAI·AutoGen·LlamaIndex vb. — OpenTelemetry/OpenInference standart biçiminde enstrümante edilmiş izleri ayrıştırır (biçim desteği var; framework bazında gerçek ölçüm doğrulaması sürüyor)
Herkese açık benchmark izleri (Toolathlon, RedundancyBench)
Cursor ve Codex oturumları henüz desteklenmiyor — yerel formatları inceleniyor.
[Doğrulama sonuçları]
Herkese açık benchmark (Toolathlon, 6.780 iz, 176.270 araç span’i):
8.042 tekrar çağrısı tespit edildi. Bunların %47’si gri alan (idempotent işlemler, tamamlandı beyanları); bunlar çıkarıldığında 4.251 vaka kalıyor (araç span’lerine göre %2,41). Claude Code oturumlarına (%0,80) kıyasla yaklaşık 3 kat.
Durum değiştiren araçların 1.343 tekrar çalıştırılması; buna aynı argümanlarla tekrarlanan 459 e-posta gönderimi dahil. Ancak bu, aynı aracın aynı argümanlarla tekrar çağrıldığının tespitidir; gerçekte yan etkinin gerçekleşip gerçekleşmediği doğrulanmamıştır.
Etiketleme benchmark’ı (RedundancyBench):
precision 0.826 (dosya içi tekrarlar için alt sınır tahmini). RB etiketlerinin önemli bir kısmı dosyalar arası (cross-file) tekrarlardır ve oturum bazlı analiz tasarımının kapsamı dışındadır. recall 0.157 ile düşüktür.
[Dürüstlük sınırları]
Ölçülmüş tasarruf örneği henüz yok. Tespit edip tahmin edebilir, ancak gerçek bir kullanıcının bir şeyi düzeltip faturanın gerçekten azaldığını gösteren before/after verisi 0 vakadır.
Benchmark’ta işaretlenenlerin %47’si gri alandır (idempotent yeniden çalıştırma). Filtrelemiyoruz, yalnızca sınıflandırıyoruz — salt okunur yeniden çalıştırmanın israf olup olmadığı görünmeyen bağlama bağlıdır.
sha256 tam eşleşmesi gerektiğinden çıktı azıcık bile farklıysa işaretlenmez. Recall’ın düşük olmasının nedeni budur; tasarım hassasiyet tarafında durur.
Claude Code olağanüstü iyi optimize edilmiştir. Gerçek CC oturumlarında altı aday israf kalıbı ölçtük; beşi orada yoktu. İlginç israf CC’nin kendisinde değil, çok araçlı MCP ortamında ortaya çıktı.
Maliyet tahmini (amplification) ölçüm değil tahmindir ve yalnızca Claude Code formatında mümkündür.
Doğrulanmayanı atarız
Dosya yeniden okuma dedektörü yaptık, ancak 30 vakalık örnekte insan notlandırmasında precision ön kayıt eşiğinin (%70) çok altında kaldığı için (iyimser bakışla %3,3, sıkı bakışla %0) iptal ettik. Tahminler ve sonuçlar ön kayıt belgesinde birlikte bırakıldı.