Alasan pemborosan token tidak terlihat adalah karena itu bukan kegagalan, melainkan duplikasi: membaca file yang sama dua kali, mencoba ulang dengan argumen yang sama, memanggil ulang tool yang sama. Karena itu, saya membuat CLI yang membaca trace yang sudah selesai dan menunjukkan step mana yang mengulang pekerjaan yang sudah dilakukan!
[Coba pakai]
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Berjalan lokal tanpa perlu mendaftar. Karena tidak mengunduh torch, instalasi selesai dalam beberapa detik. Python 3.12 atau lebih baru. File sesi Claude Code ada di bawah ~/.claude/projects/.
Ini output nyata saat dijalankan pada sesi Claude Code publik (258 turn):
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)
[Bagaimana penilaiannya]
Tidak menyimpan dan memvisualisasikan trace seperti Langfuse atau Phoenix. Tool ini membaca trace yang sudah selesai dan hanya menandai pemborosan.
Ada 2 tahap. Pertama, panggilan ke tool yang sama dengan argumen yang sama dikelompokkan, lalu dilihat apakah sha256 output-nya benar-benar sama. Jika output berbeda, berarti state berubah, jadi tidak ditandai.
Tidak ada penilaian oleh LLM. Jika trace yang sama dimasukkan, hasilnya selalu sama.
Pemborosan yang ditemukan diklasifikasikan menjadi empat jenis: pengulangan error (mencoba ulang error yang sama tanpa memperbaiki penyebabnya), eksekusi ulang dengan efek samping (memanggil lagi tool yang mengubah state dengan argumen yang sama), area abu-abu (pengulangan read-only — tidak ada efek samping, tetapi tetap memakai token), dan tidak dapat ditentukan. Tool seperti Bash atau PowerShell, yang efeknya bisa sangat berbeda tergantung isi argumen, tidak dinilai hanya dari namanya dan dibiarkan sebagai tidak dapat ditentukan.
[Apa yang ditemukan di data publik]
Saat dijalankan apa adanya pada benchmark Toolathlon (22 model frontier × 3 kali eksekusi, 6.780 trace, 176.270 tool span), ditemukan 8.042 panggilan duplikat.
Jika angka ini dipakai begitu saja, hasilnya berlebihan. Sebanyak 47% adalah area abu-abu (pengulangan deklarasi penyelesaian tugas, membuat ulang direktori yang sudah ada, dan semacamnya), jadi setelah dikeluarkan tersisa 4.251 kasus. Itu 2,41% dibanding total tool span.
Yang mencolok adalah 1.343 eksekusi duplikat pada tool yang mengubah state, dan dari jumlah itu 459 adalah pengiriman email berulang dengan argumen yang sama. Namun ini adalah deteksi bahwa "tool yang sama dipanggil dua kali dengan argumen yang sama", dan apakah email benar-benar terkirim dua kali tidak bisa dikonfirmasi hanya dari trace.
[Hal yang tidak terduga]
Claude Code sendiri ternyata lebih efisien dari perkiraan. Saya mengukur pola kandidat seperti membaca ulang file dan retry yang tidak bermakna sebanyak enam kali, dan lima di antaranya praktis tidak ada di sesi nyata CC. Rupanya sudah banyak dicegah lewat caching dan pemeliharaan konteks.
Pemborosan lebih tebal terjadi pada lingkungan yang memasang banyak server MCP. Ada selisih 3 kali antara CC dengan 20 tool (0,80%) dan Toolathlon dengan 523 tool (2,41%).
[Batasan]
Belum ada kasus penghematan yang terukur. Tool ini bisa mendeteksi dan memperkirakan, tetapi belum ada data bahwa seseorang melihat hasilnya, memperbaiki sesuatu, lalu tagihannya benar-benar turun.
47% area abu-abu tidak dibuang, hanya diklasifikasikan dan ditampilkan. Apakah pengulangan read-only benar-benar pemborosan bergantung pada konteks eksekusi, dan itu bagian yang tidak bisa saya nilai.
Cursor dan Codex belum didukung.
Detector yang gagal divalidasi akan dibuang. Saya sempat membuat detector baca ulang file, tetapi pada sampel 30 kasus, presisinya jauh di bawah ambang 70% (secara longgar pun 3,3%, secara ketat 0%), jadi saya matikan, dan saya meninggalkan prediksi serta hasilnya bersama-sama di dokumen praregistrasi.
[Penutup...]
Saya akan terus meneliti dan memvalidasi bidang ini!
Maaf README-nya masih berbahasa Inggris.. hiks
Jika Anda menggunakannya, saya ingin menerima masukan tentang bagian mana yang sebaiknya diperbaiki atau ditambahkan!
Mohon terus beri banyak perhatian pada clew. Terima kasih...!!
1 komentar
[Agar lebih nyaman dibaca, saya tuliskan terjemahan README dalam bahasa Korea!]
Clew
Detektor deterministik untuk menemukan pekerjaan yang terbuang dalam trace agen.
Clew membaca trace eksekusi AI agent yang sudah selesai, lalu menemukan langkah yang mengulang pekerjaan yang sudah dilakukan — memanggil ulang tool yang sama dengan argumen yang sama, mencoba ulang panggilan yang gagal dengan argumen yang sama, atau mengambil lagi informasi yang sudah ada di konteks. Karena bekerja tanpa penilaian LLM, trace yang sama akan selalu menghasilkan hasil yang sama.
pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md
Contoh output nyata yang dijalankan pada sesi Claude Code publik:
Result: WASTE DETECTED
1. requery — Read pada
.../boot.tsMengapa ini penting
Pemborosan dalam sesi AI coding agent biasanya baru terlihat dari tagihan. Semua pemanggilan tool mengembalikan 200, dan tidak ada yang melempar error, sehingga pemborosan tidak tampak. Namun di dalam trace, agen membaca file yang sama dua kali, mencoba ulang panggilan yang gagal dengan argumen yang sama, dan memanggil kembali tool yang sama dengan payload yang sama.
Karena operasi baca (read) dalam sesi coding agent memakan 65–90% token, pemborosan seperti ini menumpuk tanpa terlihat. Tool observability memang menampilkan trace, tetapi tidak memberi tahu langkah mana yang duplikat.
Apa yang dideteksi
Clew mencari tiga pola duplikasi:
repeat — tool/node yang sama dipanggil berulang
requery — tool yang sama dipanggil ulang dengan input yang sama (output sama)
pingpong — dua agen saling mengirim konten yang secara substansial sama (multi-agent)
Setiap temuan diklasifikasikan menjadi empat jenis:
error_repeat — output berupa error tetapi panggilan yang sama diulang
side_effect — menjalankan ulang tool yang mengubah state (mengirim/menulis/membuat, dll.)
idempotent — mengulang tool read-only/deklaratif (tanpa efek samping, tetapi menghabiskan token)
unclassified — tool yang tidak ada dalam pemetaan. Karena efeknya bergantung pada payload, tidak disimpulkan hanya dari nama tool (Bash/PowerShell, dll.)
[Cara kerjanya]
Ini adalah cascade 2 tahap:
Gerbang struktur — mengelompokkan pemanggilan tool yang sama dengan argumen yang sama (ternormalisasi)
Gerbang identitas — memeriksa apakah sha256 output benar-benar identik. Jika berbeda, berarti state berubah sehingga tidak diberi flag
Pemeriksaan struktur yang murah terlebih dahulu menyaring kandidat, dan pemeriksaan semantik yang mahal (embedding+cosine) hanya dijalankan saat diperlukan. Karena tidak ada penilaian LLM, hasilnya deterministik — ini penting jika ingin memasukkannya ke CI.
[Format input]
Claude Code — menganalisis JSONL sesi secara langsung
LangGraph — mendeteksi duplikasi chain dari trace
LangChain·CrewAI·AutoGen·LlamaIndex, dll. — mem-parse trace yang diinstrumentasi dalam format standar OpenTelemetry/OpenInference (dukungan format tersedia, sementara validasi pengukuran nyata per framework masih berlangsung)
Trace benchmark publik (Toolathlon, RedundancyBench)
Sesi Cursor dan Codex belum didukung — format lokalnya sedang ditinjau.
[Hasil validasi]
Benchmark publik (Toolathlon, 6.780 trace, 176.270 tool span):
Terdeteksi 8.042 panggilan duplikat. Dari jumlah itu, 47% adalah area abu-abu (operasi idempoten, deklarasi selesai), dan jika dikecualikan tersisa 4.251 kasus (2,41% dibanding tool span). Sekitar 3 kali lebih tinggi dibanding sesi Claude Code (0,80%).
Ada 1.343 eksekusi duplikat pada tool yang mengubah state, termasuk 459 pengiriman email berulang dengan argumen yang sama. Namun, ini hanya deteksi bahwa tool yang sama dipanggil duplikat dengan argumen yang sama; apakah efek samping benar-benar terjadi tidak dikonfirmasi.
Benchmark pelabelan (RedundancyBench):
precision 0,826 (estimasi batas bawah untuk duplikasi dalam file). Banyak label RB adalah duplikasi lintas-file (cross-file), yang berada di luar cakupan desain analisis per sesi. recall rendah, yaitu 0,157.
[Batas kejujuran]
Belum ada kasus penghematan yang terukur. Ini bisa mendeteksi dan memperkirakan, tetapi data before/after pengguna nyata yang memperbaiki sesuatu lalu tagihannya benar-benar turun masih 0 kasus.
47% dari yang diberi flag di benchmark adalah area abu-abu (eksekusi ulang idempoten). Kami tidak menyaringnya, hanya mengklasifikasikannya — karena apakah eksekusi ulang read-only itu pemborosan bergantung pada konteks yang tidak terlihat.
Karena mensyaratkan kecocokan penuh sha256, perbedaan output sekecil apa pun tidak akan diberi flag. Ini alasan recall rendah, dan desainnya memang condong ke precision.
Claude Code sangat teroptimasi. Dalam sesi CC nyata, kami mengukur enam pola kandidat pemborosan, tetapi lima di antaranya tidak ada di sana. Pemborosan yang menarik muncul bukan di CC itu sendiri, melainkan di lingkungan MCP multi-tool.
Estimasi biaya (amplification) bukan pengukuran, melainkan perkiraan, dan hanya tersedia pada format Claude Code.
Yang tidak tervalidasi kami buang
Kami sempat membuat detektor pembacaan ulang file, tetapi setelah anotasi manusia pada sampel 30 kasus, precision jauh di bawah ambang praregistrasi (70%)—3,3% bahkan jika dinilai longgar, 0% jika ketat—sehingga kami membuangnya. Prediksi dan hasilnya tetap dicatat bersama dalam dokumen praregistrasi.