Mengapa Sesi OpenClaw Saya Membakar 21,5 Juta Token dalam Sehari (Dan Apa yang Benar-Benar Memperbaikinya)
Penulis asli: MOSHIII
Terjemahan asli: Peggy, BlockBeats
Catatan editor: Di tengah adopsi cepat aplikasi Agent, banyak tim menemukan fenomena yang tampaknya kontradiktif: sistem berjalan normal, tetapi biaya token terus meningkat tanpa disadari. Melalui analisis terhadap beban kerja OpenClaw yang nyata, ditemukan bahwa penyebab ledakan biaya sering kali bukan berasal dari input pengguna atau output model, melainkan dari cache konteks yang diulang (cached prefix replay) yang diabaikan. Model secara berulang membaca konteks historis yang besar dalam setiap panggilan, menghasilkan konsumsi token yang sangat besar.
Artikel ini menggabungkan data sesi spesifik untuk menunjukkan bagaimana output alat, tangkapan layar browser, log JSON, dan hasil menengah besar lainnya terus-menerus ditulis ke konteks historis dan dibaca ulang dalam siklus agen.
Melalui kasus ini, penulis mengusulkan serangkaian pendekatan optimasi yang jelas: mulai dari desain struktur konteks, manajemen output alat, hingga konfigurasi mekanisme compaction. Bagi pengembang yang sedang membangun sistem Agent, ini bukan hanya catatan pemecahan masalah teknis, tetapi juga panduan nyata untuk menghemat biaya.
Berikut adalah teks aslinya:
Saya menganalisis beban kerja OpenClaw yang nyata dan menemukan pola yang saya yakin akan dikenali oleh banyak pengguna Agent:
Penggunaan token tampak sangat 'aktif'
Balasan tampaknya juga normal
Namun, konsumsi token tiba-tiba meledak pesat
Berikut adalah dekomposisi struktur, penyebab mendasar, dan jalur perbaikan yang dapat diimplementasikan untuk analisis ini.
TL;DR
Faktor pendorong biaya terbesar bukanlah pesan pengguna yang terlalu panjang, melainkan sejumlah besar prefiks cache yang diputar ulang berulang-ulang.
Dari data sesi:
Total token: 21.543.714
cacheRead: 17.105.970 (79,40%)
4.345.264 (20,17%)
output: 92.480 (0,43%)
Dengan kata lain: sebagian besar biaya panggilan sebenarnya bukan untuk menangani niat pengguna baru, tetapi untuk membaca berulang-ulang konteks historis yang sangat besar.
Momen "Tunggu sebentar, kenapa bisa begitu?"
Saya awalnya mengira penggunaan token tinggi berasal dari: prompt pengguna yang sangat panjang, banyak output yang dihasilkan, atau pemanggilan alat yang mahal.
Namun pola yang benar-benar mendominasi adalah:
Beberapa ratus hingga beberapa ribu token
cacheRead: Setiap panggilan 170.000 hingga 180.000 token
Artinya, model membaca kembali prefix stabil yang sangat besar yang sama pada setiap putaran.
Rentang data
Saya menganalisis data dari dua tingkat:
1. Log runtime
2. Rekam sesi (session transcripts)
Perlu ditekankan bahwa:
Log operasi terutama digunakan untuk mengamati sinyal perilaku (seperti restart, kesalahan, masalah konfigurasi)
Statistik token yang akurat berasal dari bidang usage dalam JSONL sesi
Script yang digunakan:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
File analisis yang dihasilkan:
tmp/session_token_stats_v2.txt
tmp/session_token_stats_v2.json
tmp/session_duplicate_waste.txt
tmp/session_duplicate_waste.json
tmp/session_duplicate_waste.png
Di mana token benar-benar dikonsumsi?
1) Sesi terpusat
Satu sesi menghabiskan sumber daya jauh lebih tinggi daripada yang lain:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19.204.645 token
Kemudian terjadi penurunan tajam yang jelas:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1.505.038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649.584
2) Perilaku terfokus
Token terutama berasal dari:
toolUse：16.372.294
berhenti: 5.171.420
Masalah utama terletak pada siklus pemanggilan alat, bukan obrolan biasa.
3) Waktu terkonsentrasi
Puncak token bukan acak, tetapi terkonsentrasi pada beberapa periode jam:
2026-03-08 16:00: 4.105.105
2026-03-08 09:00: 4.036.070
2026-03-08 07:00: 2.793.648
Apa yang sebenarnya ada di dalam prefix cache yang sangat besar?
Bukan isi percakapan, tetapi terutama produk antara besar:
Blok data toolResult yang sangat besar
Jejak pemikiran / penalaran yang panjang
Snapshot JSON besar
Daftar file
Browser mengambil data
Riwayat percakapan Sub-Agent
Dalam sesi terbesar, jumlah karakter sekitar:
366.469 karakter
assistant:thinking：331,494 karakter
53.039 karakter
Setelah konten ini disimpan dalam konteks historis, setiap panggilan berikutnya mungkin membacanya kembali melalui awalan cache.
Contoh spesifik (dari file sesi)
Blok konteks besar muncul berulang-ulang di lokasi berikut:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Log JSON gerbang besar (sekitar 37.000 karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Snapshot browser + enkapsulasi aman (sekitar 29.000 karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Daftar file besar yang dihasilkan (sekitar 41.000 karakter)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status Snapshot status + struktur prompt besar (sekitar 30.000 karakter)
"Kemubaziran konten berulang" vs "Beban cache replay"
Saya juga mengukur proporsi konten berulang di dalam satu panggilan:
Persentase pengulangan sekitar: 1.72%
Memang ada, tetapi bukan masalah utama.
Masalah sebenarnya adalah: volume absolut dari prefiks cache terlalu besar
Struktur adalah: konteks historis yang sangat besar, membaca ulang setiap panggilan, dengan hanya menambahkan sedikit input baru di atasnya
Oleh karena itu, fokus optimasi bukan pada penghapusan duplikasi, tetapi pada desain struktur konteks.
Mengapa siklus Agent sangat rentan mengalami masalah ini?
Tiga mekanisme saling bertumpukan:
1. Sejumlah besar alat keluaran ditulis ke konteks historis
2. Alur alat akan menghasilkan banyak panggilan dengan interval singkat
3. Perubahan awalan sangat kecil → cache akan selalu dibaca ulang
Jika kompaksi konteks tidak terpicu secara stabil, masalah akan cepat membesar.
Strategi perbaikan paling penting (diurutkan berdasarkan dampak)
P0—Jangan memasukkan output alat besar ke dalam konteks jangka panjang
Untuk output alat super besar:
- Simpan ringkasan + jalur/rujukan ID
- Menulis payload asli ke file artifact
- Jangan simpan seluruh teks asli di riwayat chat
Prioritaskan pembatasan kategori ini:
- JSON besar
- Daftar panjang
- Full browser snapshot
- Transkrip lengkap Sub Agent
P1—Pastikan mekanisme compaction benar-benar berfungsi
Dalam data ini, masalah kompatibilitas konfigurasi muncul beberapa kali: compaction key tidak valid
Ini akan secara diam-diam menutup mekanisme optimasi.
Yang benar: hanya gunakan konfigurasi yang kompatibel dengan versi
Kemudian verifikasi:
openclaw doctor --fix
Periksa log peluncuran untuk memastikan compaction diterima.
P1—Kurangi persistensi teks reasoning
Hindari teks penalaran panjang yang diputar ulang berulang-ulang
Di lingkungan produksi: simpan ringkasan singkat, bukan reasoning lengkap
P3—Perbaikan desain caching prompt
Tujuannya bukan memaksimalkan cacheRead. Tujuannya adalah menggunakan cache pada prefix yang ringkas, stabil, dan bernilai tinggi.
Saran:
- Masukkan aturan stabil ke dalam system prompt
- Jangan masukkan data yang tidak stabil ke dalam awalan stabil
- Hindari menyuntikkan sejumlah besar data debug setiap putaran
Rencana stop-loss praktis (jika saya harus menanganinya besok)
1. Temukan sesi dengan persentase cacheRead tertinggi
2. Jalankan /compact pada sesi runaway
3. Tambahkan pemotongan + artefak ke output alat
4. Jalankan ulang statistik token setelah setiap perubahan
Pantau empat KPI utama:
cacheRead / totalTokens
toolUse avgTotal/call
Jumlah panggilan >=100k token
Persentase sesi maksimum
Sinyal sukses
Jika optimasi berfungsi, Anda seharusnya melihat:
Pemanggilan token 100k+ jelas berkurang
Persentase cacheRead menurun
Bobot pemanggilan toolUse turun
Tingkat dominasi dalam satu sesi menurun
Jika indikator-indikator ini tidak berubah, berarti strategi konteks Anda masih terlalu longgar.
Perintah eksperimen replikasi
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--20 teratas \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--20 teratas \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
Penutup
Jika sistem Agent Anda tampaknya berjalan normal, tetapi biaya terus meningkat, periksa terlebih dahulu masalah ini: apakah Anda membayar inferensi baru, atau sedang memutar ulang konteks lama dalam skala besar?
Dalam kasus saya, sebagian besar biaya sebenarnya berasal dari konteks replay.
Setelah Anda menyadari hal ini, solusinya menjadi jelas: kendalikan secara ketat data yang masuk ke konteks jangka panjang.