WaveSpeedAI
← Blog

Cara Mengurangi Biaya Token Agen dalam Alur Kerja CLI

Panduan praktis untuk mengurangi biaya token agen dalam alur kerja CLI menggunakan kompresi output, kebersihan perintah, dan disiplin konteks.

By Dora 10 min read

Saya Dora. Saya menjalankan satu perintah npm test melalui Claude Code bulan lalu dan menyaksikan sesi tersebut membakar sekitar 12.000 token input sebelum agen mengucapkan sepatah kata pun kepada saya. Output test-nya 400 baris. Mungkin 30 di antaranya yang penting. Sisanya — peringatan deprecasi, noise dependensi, titik-titik progres Jest — semuanya langsung masuk ke konteks model. Saya membayar setiap byte-nya.

Itulah saat saya berhenti memperlakukan token sebagai “sesuatu yang ditangani model” dan mulai memperlakukannya sebagai anggaran yang secara aktif saya bocorkan. Jika Anda menjalankan alur kerja CLI agentic di Claude Code, Gemini CLI, atau yang serupa, ini mungkin item biaya terbesar Anda — dan solusinya bukan model yang lebih baik, melainkan kebersihan yang lebih baik. Dokumentasi manajemen biaya Anthropic sendiri menyatakannya dengan jelas: biaya token bertambah seiring ukuran konteks, dan sebagian besar optimasi terjadi sebelum model melihat data. Tulisan ini membahas cara mengurangi biaya token agen dalam alur kerja CLI tanpa kehilangan sinyal debugging yang Anda butuhkan.

Di Mana Alur Kerja CLI Membuang Token

Sebelum memperbaiki apa pun, saya harus mencari tahu di mana kebocoran terjadi. Dua pola menonjol, dan keduanya muncul di hampir setiap alur kerja CLI yang telah saya audit sejak saat itu.

Perintah Verbose dan Output yang Tidak Relevan

Perintah terminal dirancang untuk manusia yang memindai layar, bukan untuk LLM yang membaca byte per byte. git status mencetak kode ANSI yang tidak dibutuhkan model. npm install membuang ribuan baris dependency tree yang sudah diketahui model. next build menggaungkan progresnya sendiri selama lima belas detik. Tidak ada yang sepadan dengan tempatnya di jendela konteks.

Angkanya lebih buruk dari yang terlihat di atas kertas. Satu kali menjalankan cargo test pada proyek Rust berukuran sedang bisa menghasilkan 8.000–15.000 token output. Sebagian besar adalah noise kompilasi. Ketika agen membaca semuanya untuk menemukan satu assertion yang gagal, Anda telah membayar dengan tarif kelas Opus untuk hak istimewa melakukan streaming build log.

Inilah juga mengapa proyek komunitas seperti rtk dan tokf ada — mereka duduk di antara shell dan agen, menyaring boilerplate sebelum masuk ke konteks, dan melaporkan penghematan dalam kisaran 70–90% pada perintah umum. Baik Anda menggunakan wrapper atau tidak, prinsipnya tetap berlaku: output terminal mentah bukan data yang siap untuk LLM.

Carry-Over Konteks dan Pembacaan Berulang

Kebocoran kedua lebih halus. Setiap pemanggilan tool yang dilakukan agen — pembacaan file, grep, perintah bash — tetap ada dalam riwayat percakapan. Pada giliran kesepuluh, model memproses ulang sembilan giliran output yang sudah usang di setiap permintaan. Postmortem April Anthropic sendiri tentang masalah kualitas Claude Code menggambarkan dinamika ini dengan tepat: bug caching menyebabkan riwayat thinking bertumpuk di setiap giliran, dan penggunaan token meningkat 10–20x sebelum ada yang menyadarinya. Bahkan tanpa bug, ini adalah perilaku default. Sesi yang panjang adalah sesi yang mahal.

Saya memeriksa salah satu sesi saya yang sudah seminggu. Agen telah membaca package.json yang sama empat kali. Tidak ada pembacaan ulang yang menambah informasi — file-nya tidak berubah. Itu hanya artefak dari agen yang tidak tahu apa yang sudah diketahuinya.

Langkah 1: Kompres Output yang Berisik

Perbaikan termurah, dengan selisih yang jauh, adalah mencegah sampah masuk ke konteks sejak awal. Tiga aturan, dalam urutan ini:

Filter di sumbernya, bukan setelahnya. Alih-alih npm test, agen menjalankan npm test —silent 2>&1 | grep -E “(FAIL|PASS|Error)”. Alih-alih git status, jalankan git status —short. Alih-alih cargo build, jalankan cargo build —quiet 2>&1 | tail -20. Tidak ada yang cerdas di sini. Ini hanya disiplin. Agen mendapatkan test yang gagal, file yang dimodifikasi, error yang sebenarnya — tidak ada yang lain.

Batasi output tool di level harness. Claude Code memungkinkan Anda mengatur ukuran output tool maksimum. Saya menurunkan milik saya menjadi 8.000 karakter per panggilan. Ketika sebuah perintah melebihinya, agen mendapat pemberitahuan pemotongan dan memutuskan apakah akan menyempurnakan query. Pengaturan tunggal ini menghemat lebih banyak token dibanding semua perubahan lain yang saya lakukan.

Gunakan proxy CLI ketika tool upstream tidak mau diam. Beberapa perintah tidak memiliki flag quiet yang berguna — next build, webpack, apa pun yang berbasis Java. Untuk ini, wrapper yang menyaring boilerplate yang diketahui sepadan dengan waktu pengaturannya. Tool dari keluarga rtk/tokf menangani ini secara generik; Anda juga bisa menulis fungsi bash 30 baris untuk tiga perintah yang paling mengganggu Anda.

Ada trade-off nyata di sini. Kompresi agresif dapat menyembunyikan sinyal debugging. Ketika build gagal karena alasan yang disaring filter — peringatan deprecasi yang berubah menjadi error, masalah konfigurasi obscure yang terkubur di baris 847 — agen mendapatkan gambaran yang lebih pendek dan kurang berguna. Saya mengalaminya dua kali. Kedua kalinya solusinya adalah melonggarkan satu aturan filter, bukan meninggalkan strateginya.

Langkah 2: Batasi Konteks Sebelum Mencapai Model

Pemfilteran output menangani token baru yang masuk di setiap giliran. Disiplin konteks menangani token yang terakumulasi sudah ada di dalam sesi. Masalah yang berbeda.

Dua perintah yang penting, keduanya langsung dari praktik terbaik Claude Code Anthropic, adalah /clear dan /compact. /clear mereset sesi sepenuhnya — berguna saat beralih ke tugas yang tidak terkait. /compact merangkum riwayat sebelumnya sambil mempertahankan keputusan kunci dan status saat ini — berguna ketika tugas berlanjut tetapi eksplorasi awal tidak lagi relevan. Claude Code melakukan kompaksi otomatis saat mendekati batas konteks, tetapi menunggu trigger tersebut biasanya sudah terlambat. Pada saat itu Anda sudah membayar tarif yang meningkat untuk beberapa giliran.

Kebiasaan saya saat ini: saya menjalankan /compact di setiap batas tugas alami, dengan instruksi seperti /compact Focus on the failing test and the recent file edits. Instruksi itu penting. Tanpanya, kompaksi merangkum semuanya secara kasar. Dengannya, agen menyimpan bagian-bagian yang penting untuk fase berikutnya.

Untuk agen berbasis API (bukan langganan CLI), dokumentasi pengeditan konteks Anthropic menjelaskan mekanisme yang lebih ketat: clear_tool_uses_20250919 secara otomatis membersihkan hasil tool lama begitu konteks melampaui ambang batas. Agen mempertahankan percakapan tetapi kehilangan output mentah yang sudah diproses. Untuk tugas agentic berhorizon panjang, ini adalah default yang tepat.

Satu hal yang ingin saya tandai: CLAUDE.md yang membengkak adalah pajak permanen. Ia dimuat setiap giliran, setiap sesi, selamanya. Saya memangkas milik saya dari ~280 baris menjadi ~90. Jumlah token per giliran turun secara nyata dan perilaku agen tidak berubah dengan cara apa pun yang bisa saya ukur.

Langkah 3: Desain Ulang Tooling Agen untuk Pemborosan yang Lebih Rendah

Dua langkah pertama bersifat taktis. Yang ini bersifat struktural, dan di sinilah penghematan yang tahan lama berada.

Rancang tool yang menghasilkan output ramah LLM. CLI Spec yang digerakkan komunitas membuat argumen ini lebih baik dari yang bisa saya lakukan: perintah yang dimaksudkan untuk agen harus mendukung flag —output, memisahkan data (stdout) dari diagnostik (stderr), dan menyediakan paginasi alih-alih membuang JSON tanpa batas. Jika Anda membangun CLI internal yang akan dipanggil agen Anda, ikuti spec tersebut. Jika Anda menggunakan CLI eksternal yang tidak melakukannya, bungkus mereka.

Utamakan tool yang sempit daripada yang luas. Fungsi git_status_summary yang mengembalikan tiga field terstruktur lebih baik daripada membiarkan agen menjalankan git status mentah dan mengurai outputnya. Setiap lapisan penguraian yang harus dilakukan model adalah lapisan di mana token dibakar untuk terjemahan daripada penalaran. Saya mengonversi empat perintah yang paling sering saya gunakan menjadi wrapper Python tipis yang mengembalikan JSON. Penggunaan token pulang-pergi pada operasi tersebut turun sekitar 60%.

Gunakan ​subagen​​ untuk pekerjaan yang banyak membaca. Fitur subagen Claude Code menjalankan konteks terpisah untuk tugas seperti “pindai repo dan rangkum alur auth.” Temuan dikembalikan sebagai ringkasan yang kompak — bukan 40 file yang sebenarnya dibaca subagen. Percakapan utama tidak pernah melihat data mentah. Untuk tugas yang banyak eksplorasi, ini adalah kemenangan struktural terbesar yang tersedia.

Cocokkan model dengan pekerjaan. Opus 4.7 mengesankan dan mahal. Sebagian besar pekerjaan CLI — pengeditan file, perbaikan test, refactor rutin — berjalan dengan baik di Sonnet, dengan biaya per token sekitar 40% dari Opus. Patut diketahui: tokenizer baru Opus 4.7 dapat menghasilkan hingga 35% lebih banyak token untuk teks yang identik dibandingkan model sebelumnya, yang memperparah kesenjangan biaya.

Peringatan yang jujur: ukur sebelum mengoptimalkan, lalu ukur setelahnya. Saya menetapkan baseline dengan /cost (API) atau /usage (langganan) selama seminggu sebelum mengubah apa pun, kemudian mengukur ulang setelah setiap perubahan. Dua dari “optimasi” saya ternyata tidak menghasilkan apa pun yang terukur. Tanpa baseline, Anda hanya menebak.

FAQ

Mengapa alur kerja terminal mengonsumsi begitu banyak token?

Karena output terminal dirancang untuk manusia, dan agen membayar byte per byte. Perintah build tipikal menghasilkan ribuan baris progres, peringatan, dan boilerplate yang tidak dibutuhkan model. Gabungkan itu dengan riwayat percakapan yang tidak pernah direset dan hasil tool yang terakumulasi di setiap giliran, dan Anda mendapatkan sesi yang menghabiskan anggaran konteks sebelum pekerjaan sebenarnya dimulai.

Seberapa besar kompresi output bisa membantu?

Dalam pengukuran saya, pemfilteran di level perintah ditambah batas output memotong token input per giliran sebesar 40–60% pada test run, build, dan operasi git. Wrapper komunitas seperti rtk melaporkan pengurangan 80–90% pada perintah tertentu, meskipun angka tersebut mengasumsikan output verbose kasus terburuk. Keuntungan realistis bergantung pada perintah mana yang paling sering dijalankan agen Anda. Audit lima teratas, perbaiki yang itu, dan sebagian besar penghematan langsung terlihat.

Apa yang harus dioptimalkan tim terlebih dahulu?

Dalam urutan ini: batas output tool, disiplin /clear dan /compact, pemilihan model. Batas output adalah perubahan konfigurasi satu kali dengan biaya berkelanjutan nol. Kebersihan sesi adalah kebiasaan, tetapi gratis begitu Anda memilikinya. Pemilihan model adalah kemenangan termudah yang sering diabaikan — menjalankan semuanya di Opus ketika sebagian besar tugas berjalan baik di Sonnet adalah kebocoran yang diam-diam namun besar.

Kapan optimasi token merugikan kualitas debugging?

Ketika Anda mengompres melampaui titik di mana agen dapat melihat apa yang rusak. Stack trace yang terpotong, peringatan deprecasi yang tersaring, flag —quiet yang menyembunyikan error sebenarnya — semuanya telah menghabiskan waktu nyata saya. Pola yang saya ikuti: kompres secara agresif pada perintah rutin (git status, npm install, test run yang berhasil), pertahankan output verbose untuk operasi yang diketahui gagal atau tidak familiar. Jika Anda mendapati diri menjalankan ulang perintah tanpa filter untuk debugging, filternya yang salah, bukan strateginya.

Kesimpulan

Biaya token dalam alur kerja CLI bukan masalah model. Ini masalah plumbing. Sebagian besar pengeluaran menghilang ke celah antara apa yang dihasilkan perintah terminal dan apa yang sebenarnya dibutuhkan model untuk melakukan penalaran — dan celah itu bisa diperbaiki dengan pemfilteran output, disiplin konteks, dan tooling yang menghormati agen di ujung lainnya.

Saya telah menjalankan setup di atas selama sekitar enam minggu. Konsumsi token harian di Claude Code turun sekitar 55%, latensi agen membaik sebagai efek samping dari konteks yang lebih kecil, dan alur kerja terasa kurang berisik untuk di-debug. Tidak ada angka yang universal — baseline dan lima perintah teratas Anda akan terlihat berbeda. Tetapi polanya tetap berlaku: kendalikan apa yang masuk ke konteks, kendalikan apa yang tetap ada di konteks, dan biarkan model menghabiskan anggarannya untuk penalaran daripada membaca build log.

Di situlah data saya berakhir. Lapisan kompresi terus berkembang, dan perubahan tokenizer Anthropic berarti angka-angka ini memiliki masa berlaku. Sebaiknya lakukan re-baseline setiap kuartal.

Postingan sebelumnya：

Bagikan