Home
Blog
Mengapa Agen AI seperti OpenClaw Membakar Token dan Cara Memotong Biaya

Mengapa Agen AI seperti OpenClaw Membakar Token dan Cara Memotong Biaya

Engineering

February 28, 2026

Min Yin

Jika Anda pernah menghabiskan waktu dengan OpenClaw (sebelumnya Clawdbot dan Moltbot), Anda sudah tahu betapa bagusnya Agen AI ini. Cepat, lokal, fleksibel, dan mampu melakukan alur kerja yang sangat kompleks di Slack, Discord, basis kode Anda, dan hampir semua hal lain yang Anda hubungkan dengannya. Tetapi begitu Anda mulai menggunakannya secara serius, satu pola dengan cepat muncul: penggunaan token Anda mulai meningkat.

Ini bukan kesalahan OpenClaw secara khusus - ini adalah perilaku sebagian besar agen AI saat ini. Mereka memicu panggilan LLM untuk hampir semua hal: mencari file, merencanakan tugas, menulis catatan, mengeksekusi alat, atau mengajukan pertanyaan lanjutan. Dan karena token adalah mata uang universal dari panggilan ini, setiap tindakan memiliki biaya.

Untuk memahami dari mana biaya tersebut berasal, kita perlu melihat di balik dua kontributor besar:

Pencarian: Pencarian yang dibangun dengan buruk menarik muatan konteks yang luas - seluruh file, log, pesan, dan wilayah kode yang sebenarnya tidak dibutuhkan oleh model.
Memori: Menyimpan informasi yang tidak penting memaksa agen untuk membaca ulang dan memprosesnya kembali pada panggilan di masa mendatang, sehingga menambah penggunaan token dari waktu ke waktu.

Kedua masalah ini secara diam-diam meningkatkan biaya operasional tanpa meningkatkan kemampuan.

Bagaimana Agen AI Seperti OpenClaw Sebenarnya Melakukan Pencarian - dan Mengapa Itu Membakar Token

Ketika agen membutuhkan informasi dari basis kode atau pustaka dokumen Anda, biasanya agen melakukan hal yang setara dengan Ctrl+F di seluruh proyek. Setiap baris yang cocok akan dikembalikan - tanpa peringkat, tanpa filter, dan tanpa prioritas. Claude Code mengimplementasikan ini melalui alat Grep khusus yang dibangun di atas ripgrep. OpenClaw tidak memiliki alat pencarian basis kode bawaan, tetapi alat eksekusinya memungkinkan model yang mendasari menjalankan perintah apa pun, dan keterampilan yang dimuat dapat memandu agen untuk menggunakan alat seperti rg. Pada kedua kasus tersebut, pencarian basis kode mengembalikan kecocokan kata kunci tanpa peringkat dan tanpa filter.

Pendekatan brute-force ini bekerja dengan baik dalam proyek-proyek kecil. Namun, seiring dengan pertumbuhan repositori, begitu pula dengan harganya. Kecocokan yang tidak relevan akan menumpuk di jendela konteks LLM, memaksa model untuk membaca dan memproses ribuan token yang sebenarnya tidak diperlukan. Satu pencarian yang tidak tercakup dapat menyeret file lengkap, blok komentar yang besar, atau log yang memiliki kata kunci yang sama tetapi tidak memiliki maksud yang mendasarinya. Ulangi pola tersebut dalam sesi debugging atau penelitian yang panjang, dan bloat akan bertambah dengan cepat.

Baik OpenClaw dan Claude Code mencoba mengelola pertumbuhan ini. OpenClaw memangkas keluaran alat yang terlalu besar dan memadatkan riwayat percakapan yang panjang, sementara Claude Code membatasi keluaran pembacaan file dan mendukung pemadatan konteks. Mitigasi ini berhasil - tetapi hanya setelah kueri yang membengkak dieksekusi. Hasil pencarian yang tidak diberi peringkat masih menggunakan token, dan Anda masih membayar untuk itu. Manajemen konteks membantu pergantian di masa mendatang, bukan panggilan asli yang menghasilkan pemborosan.

Bagaimana Memori Agen AI Bekerja dan Mengapa Ini Juga Membutuhkan Token

Pencarian bukan satu-satunya sumber biaya token. Setiap bagian dari konteks yang diambil agen dari memori juga harus dimuat ke dalam jendela konteks LLM, dan itu juga membutuhkan token.

API LLM yang diandalkan sebagian besar agen saat ini tidak memiliki status: API Pesan Anthropic membutuhkan riwayat percakapan lengkap dengan setiap permintaan, dan API Penyelesaian Obrolan OpenAI bekerja dengan cara yang sama. Bahkan API Respons stateful yang lebih baru dari OpenAI, yang mengelola status percakapan di sisi server, masih menagih jendela konteks penuh pada setiap panggilan. Memori yang dimuat ke dalam konteks membutuhkan biaya token terlepas dari bagaimana cara mendapatkannya.

Untuk menyiasatinya, kerangka kerja agen menulis catatan ke file di disk dan memuat catatan yang relevan kembali ke jendela konteks ketika agen membutuhkannya. Sebagai contoh, OpenClaw menyimpan catatan yang dikurasi di MEMORY.md dan menambahkan log harian ke file Markdown yang diberi cap waktu, kemudian mengindeksnya dengan BM25 hibrida dan pencarian vektor sehingga agen dapat mengingat konteks yang relevan sesuai permintaan.

Desain memori OpenClaw bekerja dengan baik, tetapi membutuhkan ekosistem OpenClaw yang lengkap: proses Gateway, koneksi platform perpesanan, dan seluruh stack. Hal yang sama juga berlaku untuk memori Claude Code, yang terikat dengan CLI-nya. Jika Anda membangun agen khusus di luar platform ini, Anda memerlukan solusi mandiri. Bagian selanjutnya membahas alat yang tersedia untuk kedua masalah tersebut.

Cara Menghentikan OpenClaw Agar Tidak Membakar Token

Jika Anda ingin mengurangi jumlah token yang dikonsumsi OpenClaw, ada dua cara yang dapat Anda lakukan.

Yang pertama adalah pengambilan yang lebih baik - mengganti pembuangan kata kunci gaya grep dengan alat pencarian yang diperingkat dan digerakkan oleh relevansi sehingga model hanya melihat informasi yang benar-benar penting.
Yang kedua adalah memori yang lebih baik - berpindah dari penyimpanan yang tidak jelas dan bergantung pada kerangka kerja ke sesuatu yang dapat Anda pahami, periksa, dan kendalikan.

Mengganti grep dengan Pencarian yang Lebih Baik: index1, QMD, dan Milvus

Banyak agen pengkodean AI mencari basis kode dengan grep atau ripgrep. Claude Code memiliki alat Grep khusus yang dibangun di atas ripgrep. OpenClaw tidak memiliki alat pencarian basis kode bawaan, tetapi alat eksekusinya memungkinkan model yang mendasarinya menjalankan perintah apa pun, dan keterampilan seperti ripgrep atau QMD dapat dimuat untuk memandu bagaimana agen mencari. Tanpa keterampilan yang berfokus pada pencarian, agen akan kembali ke pendekatan apa pun yang dipilih oleh model yang mendasarinya. Masalah intinya sama untuk semua agen: tanpa pencarian berperingkat, kecocokan kata kunci akan masuk ke jendela konteks tanpa disaring.

Hal ini berhasil ketika sebuah proyek cukup kecil sehingga setiap kecocokan dapat masuk dengan nyaman ke dalam jendela konteks. Masalahnya dimulai ketika basis kode atau pustaka dokumen berkembang hingga mencapai titik di mana sebuah kata kunci menghasilkan puluhan atau ratusan hit dan agen harus memuat semuanya ke dalam prompt. Pada skala tersebut, Anda membutuhkan hasil yang diurutkan berdasarkan relevansi, bukan hanya disaring berdasarkan kecocokan.

Solusi standarnya adalah pencarian hibrida, yang menggabungkan dua metode peringkat yang saling melengkapi:

BM25 memberi nilai setiap hasil berdasarkan seberapa sering dan seberapa unik sebuah istilah muncul dalam dokumen tertentu. Sebuah berkas terfokus yang menyebutkan "otentikasi" sebanyak 15 kali memiliki peringkat yang lebih tinggi daripada berkas luas yang menyebutkannya sekali.
Pencarian vektor mengubah teks menjadi representasi numerik dari makna, sehingga "autentikasi" dapat cocok dengan "alur masuk" atau "manajemen sesi" meskipun tidak memiliki kata kunci yang sama.

Tidak satu pun dari kedua metode ini yang memadai: BM25 melewatkan istilah yang diparafrasekan, dan pencarian vektor melewatkan istilah yang tepat seperti kode kesalahan. Menggabungkan keduanya dan menggabungkan daftar peringkat melalui algoritme fusi dapat menutupi kedua celah tersebut.

Alat-alat di bawah ini mengimplementasikan pola ini pada skala yang berbeda. Grep adalah garis dasar yang digunakan semua orang untuk memulai. index1, QMD, dan Milvus masing-masing menambahkan pencarian hibrida dengan kapasitas yang meningkat.

index1: pencarian hibrida cepat pada satu mesin

index1 adalah alat CLI yang mengemas pencarian hibrida ke dalam satu file database SQLite. FTS5 menangani BM25, sqlite-vec menangani kemiripan vektor, dan RRF menggabungkan daftar peringkat. Penyematan dibuat secara lokal oleh Ollama, jadi tidak ada yang keluar dari mesin Anda.

index1 memotong kode berdasarkan struktur, bukan berdasarkan jumlah baris: File markdown dipecah berdasarkan judul, file Python berdasarkan AST, JavaScript dan TypeScript berdasarkan pola regex. Ini berarti hasil pencarian mengembalikan unit yang koheren seperti fungsi lengkap atau bagian dokumentasi lengkap, bukan rentang baris sembarangan yang memotong pertengahan blok. Waktu respons adalah 40 hingga 180ms untuk kueri hibrida. Tanpa Ollama, ini kembali ke BM25 saja, yang masih mengurutkan hasil daripada membuang setiap kecocokan ke dalam jendela konteks.

index1 juga menyertakan modul memori episodik untuk menyimpan pelajaran yang dipetik, akar penyebab bug, dan keputusan arsitektur. Memori ini berada di dalam basis data SQLite yang sama dengan indeks kode, bukan sebagai file yang berdiri sendiri.

Catatan: index1 adalah proyek tahap awal (0 bintang, 4 komitmen per Februari 2026). Evaluasi dengan basis kode Anda sendiri sebelum berkomitmen.

Paling cocok untuk: pengembang tunggal atau tim kecil dengan basis kode yang muat di satu mesin, yang mencari peningkatan cepat atas grep.
Lebih baik digunakanketika: Anda membutuhkan akses multi-pengguna ke indeks yang sama, atau data Anda melebihi apa yang dapat ditangani oleh satu file SQLite dengan nyaman.

QMD: akurasi yang lebih tinggi melalui pemeringkatan ulang LLM lokal

QMD (Query Markup Documents), yang dibangun oleh pendiri Shopify, Tobi Lütke, menambahkan tahap ketiga: Pemeringkatan ulang LLM. Setelah BM25 dan pencarian vektor masing-masing mengembalikan kandidat, model bahasa lokal membaca ulang hasil teratas dan mengurutkannya kembali berdasarkan relevansi aktual dengan kueri Anda. Hal ini menangkap kasus-kasus di mana kata kunci dan kecocokan semantik mengembalikan hasil yang masuk akal tetapi salah.

QMD berjalan sepenuhnya di mesin Anda menggunakan tiga model GGUF dengan total sekitar 2 GB: model penyematan (embeddinggemma-300M), sebuah reranker penyandi silang (Qwen3-Reranker-0.6B), dan sebuah model perluasan kueri (qmd-query-expansion-1.7B). Ketiganya diunduh secara otomatis saat pertama kali dijalankan. Tidak ada panggilan API cloud, tidak ada kunci API.

Pengorbanannya adalah waktu mulai dingin: memuat tiga model dari disk membutuhkan waktu sekitar 15 hingga 16 detik. QMD mendukung mode server persisten (qmd mcp) yang menyimpan model dalam memori di antara permintaan, sehingga menghilangkan penalti mulai dingin untuk kueri yang berulang.

Terbaik untuk: lingkungan yang sangat menjaga privasi di mana tidak ada data yang dapat meninggalkan mesin Anda, dan di mana akurasi pengambilan lebih penting daripada waktu respons.
Lebih baikdigunakan ketika: Anda membutuhkan respons sub-detik, akses tim bersama, atau kumpulan data Anda melebihi kapasitas mesin tunggal.

Milvus: pencarian hibrida pada skala tim dan perusahaan

Alat-alat mesin tunggal di atas bekerja dengan baik untuk pengembang individu, tetapi mereka mencapai batas ketika beberapa orang atau agen membutuhkan akses ke basis pengetahuan yang sama.

Milvus adalah basis data vektor sumber terbuka yang dibuat untuk tahap berikutnya: terdistribusi, multi-pengguna, dan mampu menangani miliaran vektor.

Fitur utamanya untuk kasus penggunaan ini adalah Sparse-BM25 yang sudah ada di dalamnya, tersedia sejak Milvus 2.5 dan jauh lebih cepat pada versi 2.6. Anda memberikan teks mentah, dan Milvus menokenya secara internal menggunakan penganalisis yang dibangun di atas tantivy, kemudian mengubah hasilnya menjadi vektor jarang yang telah dihitung sebelumnya dan disimpan pada waktu indeks.

Karena representasi BM25 sudah tersimpan, pengambilan tidak perlu menghitung ulang skor dengan cepat. Vektor-vektor yang jarang ini berada di samping vektor-vektor yang padat (semantic embeddings) di dalam Koleksi yang sama. Pada waktu kueri, Anda menggabungkan kedua sinyal dengan pemeringkat seperti RRFRanker, yang disediakan oleh Milvus. Pola pencarian hibrida yang sama dengan index1 dan QMD, tetapi berjalan pada infrastruktur yang berskala horizontal.

Milvus juga menyediakan kemampuan yang tidak dapat dilakukan oleh alat mesin tunggal: isolasi multi-penyewa (basis data atau koleksi terpisah per tim), replikasi data dengan failover otomatis, dan tingkatan data panas/dingin untuk penyimpanan yang hemat biaya. Untuk agen, ini berarti beberapa pengembang atau beberapa contoh agen dapat meminta basis pengetahuan yang sama secara bersamaan tanpa menginjak data satu sama lain.

Paling cocok untuk: beberapa pengembang atau agen yang berbagi basis pengetahuan, kumpulan dokumen yang besar atau berkembang pesat, atau lingkungan produksi yang membutuhkan replikasi, failover, dan kontrol akses.

Kesimpulannya:

Alat	Tahap	Penyebaran	Sinyal migrasi
Claude Native Grep	Pembuatan prototipe	Bawaan, pengaturan nol	Tagihan naik atau kueri melambat
indeks1	Mesin tunggal (kecepatan)	SQLite + Ollama lokal	Membutuhkan akses multi-pengguna atau data melebihi satu mesin
QMD	Mesin tunggal (akurasi)	Tiga model GGUF lokal	Membutuhkan indeks yang digunakan bersama tim
Milvus	Tim atau Produksi	Cluster terdistribusi	Kumpulan dokumen besar atau persyaratan multi-penyewa

Mengurangi Biaya Token Agen AI dengan Memberikan Memori yang Persisten dan Dapat Diedit dengan memsearch

Pengoptimalan pencarian mengurangi pemborosan token per kueri, tetapi tidak membantu dengan apa yang disimpan oleh agen di antara sesi.

Setiap bagian dari konteks yang diambil oleh agen dari memori harus dimuat ke dalam prompt, dan itu juga membutuhkan token. Pertanyaannya bukan apakah akan menyimpan memori, tetapi bagaimana caranya. Metode penyimpanan menentukan apakah Anda dapat melihat apa yang diingat oleh agen, memperbaikinya jika salah, dan membawanya jika Anda berganti alat.

Kebanyakan kerangka kerja gagal dalam ketiga hal tersebut. Mem0 dan Zep menyimpan segala sesuatu dalam basis data vektor, yang berfungsi untuk pengambilan, tetapi membuat memori:

Buram. Anda tidak dapat melihat apa yang diingat oleh agen tanpa meminta API.
Sulit untuk diedit. Memperbaiki atau menghapus memori berarti pemanggilan API, bukan membuka file.
Terkunci. Berganti kerangka kerja berarti mengekspor, mengonversi, dan mengimpor kembali data Anda.

OpenClaw mengambil pendekatan yang berbeda. Semua memori berada dalam file Markdown biasa pada disk. Agen menulis log harian secara otomatis, dan manusia dapat membuka dan mengedit file memori secara langsung. Ini memecahkan ketiga masalah: memori dapat dibaca, diedit, dan portabel secara desain.

Pengorbanannya adalah biaya penyebaran. Menjalankan memori OpenClaw berarti menjalankan ekosistem OpenClaw secara penuh: proses Gateway, koneksi platform perpesanan, dan seluruh stack. Untuk tim yang sudah menggunakan OpenClaw, tidak masalah. Bagi orang lain, penghalang itu terlalu tinggi. memsearch dibangun untuk menutup celah ini: memsearch mengekstrak pola memori Markdown-first dari OpenClaw ke dalam pustaka mandiri yang bekerja dengan agen apa pun.

memsearch, yang dibangun oleh Zilliz (tim di belakang Milvus), memperlakukan file Markdown sebagai sumber kebenaran tunggal. MEMORY.md menyimpan fakta-fakta jangka panjang dan keputusan yang Anda tulis dengan tangan. Catatan harian (2026-02-26.md) dibuat secara otomatis dari ringkasan sesi. Indeks vektor, yang disimpan di Milvus, adalah lapisan turunan yang dapat dibangun kembali dari Markdown kapan saja.

Dalam praktiknya, ini berarti Anda dapat membuka file memori apa pun di editor teks, membaca apa yang diketahui agen, dan mengubahnya. Simpan berkas, dan pengamat berkas memsearch akan mendeteksi perubahan dan mengindeks ulang secara otomatis. Anda bisa mengelola memori dengan Git, meninjau memori yang dibuat oleh AI melalui pull request, atau berpindah ke mesin baru dengan menyalin folder. Jika indeks Milvus hilang, Anda membangunnya kembali dari file. Berkas-berkas tersebut tidak pernah berisiko.

Di balik tenda, memsearch menggunakan pola pencarian hibrida yang sama dengan yang dijelaskan di atas: potongan-potongan yang dipisahkan berdasarkan struktur judul dan batas paragraf, pengambilan vektor BM25 +, dan perintah ringkas bertenaga LLM yang meringkas ingatan lama ketika log menjadi besar.

Paling cocok untuk: tim yang menginginkan visibilitas penuh ke dalam apa yang diingat oleh agen, membutuhkan kontrol versi atas memori, atau menginginkan sistem memori yang tidak terkunci pada satu kerangka kerja agen.

Kesimpulannya:

Kemampuan	Mem0 / Zep	memsearch
Sumber kebenaran	Basis data vektor (sumber data tunggal)	File penurunan harga (primer) + Milvus (indeks)
Transparansi	Kotak hitam, membutuhkan API untuk memeriksa	Buka file .md apa pun untuk dibaca
Dapat diedit	Memodifikasi melalui panggilan API	Edit langsung di editor teks apa pun, diindeks ulang secara otomatis
Kontrol versi	Membutuhkan pencatatan audit terpisah	Git bekerja secara native
Biaya migrasi	Ekspor → ubah format → impor ulang	Salin folder Penurunan Harga
Kolaborasi manusia dan AI	AI menulis, manusia mengamati	Manusia dapat mengedit, menambah, dan meninjau

Pengaturan mana yang sesuai dengan skala Anda

Skenario	Pencarian	Memori	Kapan harus melanjutkan
Prototipe awal	Grep (bawaan)	-	Tagihan naik atau kueri melambat
Pengembang tunggal, hanya pencarian	index1 (kecepatan) atau QMD (akurasi)	-	Membutuhkan akses multi-pengguna atau data melebihi satu mesin
Pengembang tunggal, keduanya	index1	memsearch	Membutuhkan akses multi-pengguna atau data melebihi satu mesin
Tim atau produksi, keduanya	Milvus	memsearch	-
Integrasi cepat, hanya memori	-	Mem0 atau Zep	Perlu memeriksa, mengedit, atau memigrasi memori

Kesimpulan

Biaya token yang muncul dengan agen AI yang selalu aktif tidak dapat dihindari. Panduan ini membahas dua area di mana perkakas yang lebih baik dapat mengurangi pemborosan: pencarian dan memori.

Grep bekerja dalam skala kecil, tetapi seiring dengan pertumbuhan basis kode, kecocokan kata kunci yang tidak diberi peringkat membanjiri jendela konteks dengan konten yang tidak pernah dibutuhkan oleh model. index1 dan QMD mengatasi hal ini di satu mesin dengan menggabungkan penilaian kata kunci BM25 dengan penelusuran vektor dan hanya mengembalikan hasil yang paling relevan. Untuk tim, pengaturan multi-agen, atau beban kerja produksi, Milvus menyediakan pola pencarian hibrida yang sama pada infrastruktur yang berskala horizontal.

Untuk memori, sebagian besar kerangka kerja menyimpan segala sesuatu dalam basis data vektor: buram, sulit diedit dengan tangan, dan terkunci pada kerangka kerja yang membuatnya. memsearch mengambil pendekatan yang berbeda. Memori berada dalam berkas Markdown biasa yang dapat Anda baca, edit, dan kontrol versi dengan Git. Milvus berfungsi sebagai indeks turunan yang dapat dibangun kembali dari berkas-berkas tersebut kapan saja. Anda tetap memegang kendali atas apa yang diketahui oleh agen.

Baik memsearch dan Milvus adalah sumber terbuka. Kami secara aktif mengembangkan memsearch dan sangat mengharapkan umpan balik dari siapa pun yang menjalankannya dalam produksi. Buka masalah, kirimkan PR, atau beri tahu kami apa yang berhasil dan apa yang tidak.

Proyek-proyek yang disebutkan dalam panduan ini:

memsearch: Memori pertama yang dapat dideteksi untuk agen AI, didukung oleh Milvus.
Milvus: Basis data vektor sumber terbuka untuk pencarian hibrida yang dapat diskalakan.
index1: Pencarian hibrida vektor BM25 + untuk agen pengkodean AI.
QMD: Pencarian hibrida lokal dengan pemeringkatan ulang LLM.