Sesi OpenClaw membakar 21.5J token dalam sehari, strategi pengoptimuman mengurangkan kos

Mengapa Sesi OpenClaw Saya Membakar 21.5J Token Dalam Sehari (Dan Apa Yang Benar-Benar Memperbaikinya)

Penulis asal: MOSHIII

Peggy, BlockBeats

Catatan editor: Di tengah penerapan pantas aplikasi Agent, banyak pasukan mendapati fenomena yang kelihatan bertentangan: sistem berfungsi dengan lancar, tetapi kos token terus meningkat tanpa disedari. Melalui analisis beban kerja OpenClaw yang sebenar, penulis mendapati bahawa punca ledakan kos sering bukan berasal daripada input pengguna atau output model, tetapi daripada penayangan semula cache konteks (cached prefix replay) yang diabaikan. Model membaca semula konteks sejarah yang besar dalam setiap panggilan, menyebabkan penggunaan token yang sangat tinggi.

Artikel ini menggabungkan data sesi spesifik untuk menunjukkan bagaimana output alat, tangkapan layar peramban, log JSON, dan hasil sementara besar lainnya terus ditulis ke konteks sejarah dan dibaca semula dalam kitaran agen.

Melalui kes ini, penulis mengemukakan satu pendekatan pengoptimuman yang jelas: dari reka bentuk struktur konteks, pengurusan output alat hingga konfigurasi mekanisme compaction. Bagi pembangun yang sedang membina sistem Agent, ini bukan sahaja satu rekod penyiasatan teknikal, tetapi juga satu panduan penjimatan wang yang benar-benar berkesan.

Berikut ialah teks asal:

Saya menganalisis beban kerja OpenClaw yang sebenarnya dan menemukan satu corak yang saya percaya akan dikenali oleh banyak pengguna Agent:

Penggunaan token kelihatan sangat 'aktif'

Balasan kelihatan juga biasa

Namun, penggunaan token tiba-tiba meningkat secara eksponen

Berikut adalah struktur analisis, punca asal, dan laluan pembaikan yang boleh dilaksanakan.

Faktor penggerak kos terbesar bukanlah mesej pengguna terlalu panjang, tetapi sejumlah besar imbuhan tersimpan (cached prefix) yang diputar semula berulang kali.

Berdasarkan data sesi:

Jumlah token: 21,543,714

cacheRead：17,105,970（79.40%）

4,345,264 (20.17%)

output: 92,480 (0.43%)

Dengan kata lain: kebanyakan kos panggilan sebenarnya bukan dalam mengendalikan niat pengguna baru, tetapi dalam membaca semula konteks sejarah yang besar.

Saya sebelumnya menyangka penggunaan token tinggi berasal daripada: prompt pengguna yang sangat panjang, penghasilan output yang banyak, atau pemanggilan alat yang mahal.

Tetapi corak yang benar-benar menguasai adalah:

Ratusan hingga ribuan token

cacheRead：Setiap panggilan 170.000 hingga 180.000 token

Dengan kata lain, model membaca semula prefix stabil yang besar yang sama pada setiap putaran.

Saya menganalisis data dari dua tingkatan:

1. Log masa berjalan (runtime logs)

2. Transkrip sesi

Perlu ditekankan bahawa:

Log operasi digunakan terutama untuk memantau isyarat tingkah laku (seperti restart, ralat, masalah konfigurasi)

Statistik token yang tepat berasal dari medan usage dalam JSONL sesi

Skrip yang digunakan:

skrip/session_token_breakdown.py

skrip/session_duplicate_waste_analysis.py

Fail 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

1) Sesi terkumpul

Satu sesi menghabiskan lebih banyak berbanding yang lain:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 token

Kemudian adalah penurunan tajam yang jelas:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649.584

2) Perilaku terkumpul

Token utama berasal dari:

toolUse：16,372,294

berhenti：5,171,420

Masalah utama berpunca daripada kitaran panggilan alat, bukan perbualan biasa.

3) Masa terkumpul

Puncak token bukanlah rawak, tetapi terkumpul dalam beberapa tempoh masa:

2026-03-08 16:00: 4,105,105

2026-03-08 09:00: 4,036,070

2026-03-08 07:00: 2,793,648

Bukan kandungan perbualan, tetapi terutamanya produk sampingan besar:

Blok data toolResult yang besar

Jejak pemikiran / alasan yang panjang

Snapshot JSON besar

Senarai fail

Pengambilan data oleh pelayar

Rakaman perbualan Sub-Agent

Dalam sesi terbesar, jumlah aksara kira-kira:

366,469 aksara

assistant:thinking：331,494 karakter

53,039 aksara

Apabila kandungan ini disimpan dalam konteks sejarah, setiap panggilan seterusnya mungkin membaca semula mereka melalui awalan cache.

Blok konteks yang sangat besar telah muncul berulang-ulang di lokasi berikut:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

Log JSON gerbang besar (kira-kira 37,000 aksara)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

Rakaman peramban + pembungkusan selamat (kira-kira 29,000 aksara)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

Senarai fail yang besar (kira-kira 41,000 aksara)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

session/status gambaran status + struktur prompt besar (sekitar 30,000 aksara)

Saya juga mengukur nisbah kandungan berulang di dalam panggilan tunggal:

Peratusan ulangan: kira-kira 1.72%

Memang wujud, tetapi bukan masalah utama.

Masalah sebenarnya adalah: jumlah mutlak imbuhan cache terlalu besar

Struktur adalah: konteks sejarah yang besar, membaca semula setiap panggilan, hanya menambahkan sedikit input baru di atasnya

Oleh itu, fokus pengoptimuman bukanlah penghapusan duplikasi, tetapi rekabentuk struktur konteks.

Tiga mekanisme saling bertindih:

1. Sejumlah besar alat keluaran telah ditulis ke konteks sejarah

2. Perulangan alat akan menghasilkan banyak panggilan dengan jangka masa pendek

3. Perubahan awalan sangat kecil → cache akan dibaca semula setiap kali

Jika kompaksi konteks tidak dipicu secara stabil, masalah akan membesar dengan cepat.

P0—Jangan masukkan output alat yang besar ke dalam konteks jangka panjang

Untuk output alat super besar:

• Kekalkan ringkasan + laluan/rujukan ID
• Menulis payload asal ke fail artifact
• Jangan simpan seluruh teks asal dalam sejarah chat

Hadkan terlebih dahulu kategori-kategori ini:

• JSON besar
• Senarai katalog panjang
• Snapshot penuh pelayar
• Transkrip penuh Agen anak

P1—Pastikan mekanisme compaction berfungsi dengan betul

Dalam data ini, masalah kompatibilitas konfigurasi muncul berulang kali: kunci compaction tidak sah

Ini akan menutup mekanisme pengoptimuman secara senyap.

Cara yang betul: Hanya gunakan konfigurasi yang sepadan dengan versi

Kemudian sahkan:

openclaw doctor --fix

Semak log pelancaran untuk mengesahkan bahawa compaction diterima.

P1—Kurangkan pengekalan teks reasoning

Elakkan teks penalaran panjang diputar ulang berulang kali

Dalam persekitaran pengeluaran: simpan ringkasan ringkas, bukan alasan penuh

P3—Memperbaiki reka bentuk cache prompt

Matlamat bukan untuk memaksimumkan cacheRead. Matlamat adalah menggunakan cache pada awalan yang padat, stabil, dan bernilai tinggi.

Cadangan:

• Masukkan peraturan stabil ke dalam system prompt
• Jangan masukkan data tidak stabil ke dalam awalan stabil
• Hindari memasukkan sejumlah besar data debug setiap pusingan

1. Cari sesi dengan peratusan cacheRead tertinggi

2. Jalankan /compact pada sesi runaway

3. Tambahkan pemotongan + pengartifakkan kepada output alat

4. Jalankan semula pengiraan token setiap kali membuat perubahan

Pantau empat KPI utama:

cacheRead / totalTokens

toolUse avgTotal/call

Jumlah panggilan >=100k token

Peratusan sesi maksimum

Jika pengoptimuman berkesan, anda seharusnya melihat:

Pemanggilan token 100k+ jelas berkurang

Peratusan cacheRead menurun

Penurunan bobot panggilan toolUse

Kepimpinan sesi tunggal berkurang

Jika indeks-indeks ini tidak berubah, ini menunjukkan bahawa strategi konteks anda masih terlalu longgar.

python3 skrip/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 skrip/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

Jika sistem Agent anda kelihatan normal, tetapi kos terus meningkat, semak terlebih dahulu masalah ini: Adakah anda membayar inferensi baharu, atau sedang memutar semula konteks lama dalam skala besar?

Dalam kes saya, sebahagian besar kos sebenarnya datang daripada penayangan semula konteks.

Setelah anda sedar akan hal ini, penyelesaiannya menjadi jelas: kawal ketat data yang masuk ke konteks jangka panjang.

Pautan asal