AI agent memang bikin kerja developer terasa seperti naik eskalator: lebih cepat, lebih ringan, dan kadang bikin kagum sendiri. Hermes Agent, Ruflo, dan OpenClaw bisa membantu membaca repository, menelusuri error, menjalankan command, menyunting banyak file, merangkum hasil test, sampai membagi pekerjaan ke sub-agent. Produktivitas naik, eksperimen jadi lebih berani, dan banyak tugas repetitif bisa dipindahkan ke agent.
Tapi ada satu kejutan yang sering datang belakangan: tagihan token ikut naik dengan semangat yang sama. Masalahnya sering bukan karena model AI selalu mahal, melainkan karena cara kerja agent dibiarkan terlalu boros. Konteks terlalu panjang, output tool tidak dipangkas, terlalu banyak file dibaca, sub-agent dipanggil tanpa kontrol, atau model paling canggih dipakai untuk tugas yang sebenarnya sederhana.
Kabar baiknya, hemat token bukan berarti menurunkan kualitas kerja agent. Justru sebaliknya, strategi hemat token biasanya membuat alur kerja jadi lebih rapi, lebih cepat, dan lebih mudah diawasi. Intinya sederhana: kirim hanya informasi yang benar-benar dibutuhkan model untuk menyelesaikan tugas.
Hal pertama yang perlu dipahami adalah: tidak semua aktivitas agent otomatis menghabiskan token. Ketika agent menjalankan pencarian lokal, membaca file di mesin, atau menyimpan catatan ke memori, proses lokal itu sendiri belum tentu memakan token model. Token baru terpakai ketika instruksi, hasil pencarian, isi file, ringkasan memori, atau output tool dimasukkan ke prompt dan dikirim ke model.
Karena itu, sumber pemborosan biasanya ada pada ukuran konteks yang dibawa per request. Komponen yang paling sering membesar tanpa terasa antara lain system prompt, riwayat percakapan, isi file yang dibaca, hasil grep atau ripgrep, output test, skema tool, memori yang dimasukkan ulang, prompt sub-agent, dan jawaban model itu sendiri. Pada model tertentu, reasoning token juga bisa ikut berpengaruh. Jadi jangan hanya menghitung berapa kali model dipanggil. Lihat juga seberapa gemuk setiap panggilannya.
Strategi pertama yang paling berdampak adalah merapikan file bootstrap dan konteks agent. Banyak tim tanpa sadar menjadikan file seperti AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, atau BOOTSTRAP.md sebagai gudang semua hal. Isinya campur aduk: aturan proyek, catatan debugging lama, daftar task, dokumentasi API, contoh kode, sampai sejarah perubahan yang sudah tidak relevan. Hasilnya, setiap sesi dimulai dengan koper terlalu penuh.
Padahal file bootstrap idealnya ringkas dan sangat praktis. Isinya cukup hal-hal yang hampir selalu dibutuhkan agent, misalnya bahasa utama, framework, aturan arsitektur yang tidak boleh dilanggar, kebijakan migration, cara menjalankan test, atau konvensi struktur folder. Kalau ada penjelasan panjang yang hanya relevan untuk satu modul, simpan di dokumentasi modul itu saja. Jangan paksa semua sesi membawanya dari awal.
Pada OpenClaw, pengaturan konteks dan context injection membantu mengendalikan kapan file workspace disuntikkan ke prompt. OpenClaw juga menyediakan perintah untuk melihat detail komponen konteks, sehingga developer bisa mengecek apakah pemborosan berasal dari bootstrap file, transcript, skill, atau skema tool. Pada Hermes Agent, file konteks seperti SOUL.md, .hermes.md, AGENTS.md, CLAUDE.md, dan .cursorrules juga bisa ikut masuk ke system prompt, lengkap dengan batas karakter yang dapat diatur. Bahkan ada pembatasan pembacaan file agar satu file besar tidak langsung memenuhi jendela konteks.
Pelajaran pentingnya begini: agent yang pintar tidak butuh pengantar sepanjang novel. Ia lebih suka briefing singkat, jelas, dan konsisten.
Strategi kedua adalah menghindari kebiasaan memberi seluruh codebase kepada model. Ini godaan yang sangat umum. Saat muncul bug validasi, agent diminta mencari penyebabnya, lalu ia menelusuri terlalu luas, membuka banyak file, dan memasukkan semuanya ke konteks. Dari luar terlihat rajin, dari dalam dompet mulai menjerit pelan.
Lebih hemat jika pencarian dibuat bertahap dan presisi. Mulai dari simbol, nama fungsi, nama service, atau folder yang paling mungkin relevan. Gunakan pencarian terbatas ke direktori tertentu, minta hasil beberapa baris saja, lalu perluas bila memang perlu. Untuk log, kirim bagian akhir atau hanya baris yang mengandung error. Untuk diff, tampilkan file yang berubah atau satu file target, bukan seluruh repository.
Hermes Agent mendukung context reference dengan rentang baris, sehingga developer bisa menunjuk hanya bagian file yang relevan. Ini sangat berguna untuk file besar. Pola kerja hematnya adalah: cari simbol, temukan kandidat file, baca bagian terkait, lalu perluas hanya bila diperlukan. Bukan kebalikannya. Model bukan mesin tenung yang harus menelan semua isi repo agar bisa menebak bagian penting.
Strategi ketiga: pakai model sesuai tingkat kesulitan. Ini salah satu cara paling cepat menekan biaya. Tidak semua pekerjaan membutuhkan model paling kuat. Tugas seperti merangkum log, mengelompokkan error, mencari file terkait, mengubah format data, membuat test sederhana, atau menulis dokumentasi awal sering kali cukup ditangani model yang lebih ringan. Model besar lebih cocok untuk desain arsitektur, analisis akar masalah yang rumit, review keamanan, migrasi besar, atau keputusan dengan banyak trade-off.
Praktiknya bisa memakai pola orchestrator dan worker. Model besar dipakai untuk memahami tujuan, menyusun rencana, dan memeriksa hasil akhir. Sementara model yang lebih murah mengerjakan tugas rutin dan sempit. Pendekatan ini tidak otomatis gratis, karena setiap delegasi tetap menambah request. Namun jika pembagian tugasnya tepat, total biaya bisa lebih efisien daripada memaksa satu model premium menangani semua hal dari awal sampai akhir.
OpenClaw mendukung sub-agent, dan tiap sub-agent punya konteks serta konsumsi token sendiri. Artinya, membuat banyak sub-agent tanpa batas bukan strategi hemat. Pada Ruflo, pendekatan swarm memang berguna untuk coding kolaboratif, tetapi jumlah agent tetap perlu dijaga agar koordinasi tidak lebih mahal daripada manfaatnya.
Di sinilah strategi keempat masuk: gunakan swarm secukupnya. Semakin banyak agent, semakin banyak system prompt, tool schema, riwayat, dan output yang harus ditangani. Kalau satu perubahan kecil dibagi ke terlalu banyak agent, biaya koordinasi bisa mengalahkan biaya pengerjaan. Swarm cocok saat masalah benar-benar bisa dipisah jelas, misalnya satu agent fokus ke database, satu ke service layer, satu ke test, lalu agent utama menggabungkan hasil.
Kalau semua agent dibiarkan mencari hal yang sama dari sudut berbeda, itu bukan kolaborasi, melainkan lomba boros token. Agar efisien, setiap agent harus punya tanggung jawab yang tegas. Shared memory pun sebaiknya berisi hasil padat: file utama, akar masalah, keputusan teknis, test yang gagal, dan langkah berikutnya. Jangan isi shared memory dengan log mentah, isi file penuh, atau transcript panjang. Memori bersama seharusnya seperti sticky note, bukan gudang arsip.
Strategi kelima adalah membedakan tool deterministik dan AI reasoning. Ini sering terlupakan karena agent terasa serbabisa. Padahal banyak pekerjaan tidak perlu LLM sama sekali. Formatter, linter, compiler, codemod, static analyzer, regex, dan transformasi AST sering bisa menyelesaikan tugas lebih cepat, lebih murah, dan lebih konsisten.
Kalau tujuan Anda hanya mengganti pola penamaan, menghapus console tertentu, menambah logging standar, atau merapikan format, gunakan jalur deterministik bila tersedia. Ruflo secara konsep mendorong pemisahan antara transformasi yang bisa dilakukan tanpa penalaran mendalam dan tugas yang memang butuh model. Ini penting karena membayar model untuk pekerjaan yang bisa diselesaikan tool lokal itu seperti memanggil konsultan strategi untuk tugas mengganti nama file. Bisa saja, tapi sayang sekali.
Strategi keenam: potong output tool sebelum masuk ke model. Sumber pemborosan ini sangat licin karena sering tidak terlihat. Command seperti test runner, build tool, package manager, atau log server dapat menghasilkan ribuan baris. Padahal model biasanya hanya butuh ringkasan kegagalan, nama test yang error, stack trace inti, file, nomor baris, dan beberapa petunjuk utama.
Karena itu, biasakan mengirim output yang sudah dipersempit. Simpan output penuh ke file jika perlu audit, lalu berikan ke model hanya bagian pentingnya. Gunakan tail, grep, filter kata kunci, atau ringkasan test. Hermes Agent memiliki pembatasan output tool seperti jumlah byte, jumlah baris, dan panjang baris, agar konteks tidak langsung meledak. Namun pembatasan otomatis tetap bukan alasan untuk mengirim banjir output sejak awal. Lebih baik command-nya sendiri sudah hemat.
Strategi ketujuh adalah mengelola memori sebagai ringkasan keputusan, bukan tempat menyimpan semua jejak kerja. Memori agent paling berguna bila berisi aturan yang stabil, sulit ditemukan ulang, sering dipakai, dan memengaruhi keputusan berikutnya. Misalnya versi bahasa, kebijakan deployment, larangan mengubah migration lama, kewajiban idempotency key, atau aturan akses database produksi.
Yang tidak perlu masuk memori adalah hal-hal sementara: kapan build gagal, file apa yang sempat dibuka, output test yang panjang, atau daftar langkah yang sudah lewat. Hermes Agent membatasi memori tertentu agar tetap padat. Ini bukan kekurangan, melainkan pengingat desain: memori yang baik menyimpan kesimpulan, bukan seluruh perjalanan. Ibarat catatan rapat, yang penting adalah keputusan dan tindak lanjut, bukan semua kalimat yang sempat diucapkan.
Strategi kedelapan: ringkas sesi sebelum konteks membengkak. Percakapan panjang sangat mudah dipenuhi sisa-sisa masa lalu: file versi lama, asumsi awal yang sudah salah, hasil test usang, dan percobaan yang gagal. Semuanya menempel di transcript, lalu ikut terbawa pada request berikutnya. Lama-lama agent bukan hanya mengerjakan task, tetapi juga menyeret koper penuh kenangan.
OpenClaw menyediakan mekanisme compaction untuk meringkas transcript lama. Hermes menyediakan kompresi sesi. Fitur ini berguna, tetapi harus dipakai dengan disiplin. Sebelum melakukan kompresi, minta agent membuat checkpoint yang jelas: file yang berubah, keputusan arsitektur, test yang sudah dijalankan, masalah yang tersisa, dan langkah berikutnya. Ringkasan yang bagus akan menjaga inti kerja tetap utuh. Ringkasan yang asal-asalan justru berisiko menghilangkan detail penting.
Strategi kesembilan sangat relevan untuk workflow otomatis: optimalkan heartbeat dan pekerjaan berkala. Agent yang terus berjalan bisa tampak murah per siklus, tetapi kalau tiap heartbeat membawa bootstrap besar, transcript panjang, dan konteks proyek penuh, biaya dasar akan menumpuk. Padahal tugas heartbeat biasanya sederhana: memeriksa status, melihat apakah ada perubahan, lalu memutuskan perlu memberi notifikasi atau tidak.
OpenClaw menyediakan opsi lightContext dan isolatedSession untuk meringankan beban heartbeat. Prinsipnya sederhana: pekerjaan berkala sebaiknya hanya tahu apa yang perlu diperiksa, di mana status berada, kondisi apa yang dianggap berubah, dan kapan perlu memberi tahu pengguna. Ia tidak perlu membawa seluruh isi kepala agent utama. Untuk tugas monitoring, konteks kurus justru sehat.
Strategi kesepuluh: ukur biaya per task, bukan hanya per bulan. Tagihan akhir memang menunjukkan total pengeluaran, tetapi tidak menjelaskan sumber masalah. Monitoring yang berguna harus bisa menjawab task mana yang paling mahal, model mana yang paling sering dipakai, agent mana yang paling boros, output tool apa yang paling sering membengkak, dan berapa biaya untuk satu bugfix atau satu pull request.
OpenRouter menyediakan usage accounting yang memuat detail seperti prompt token, completion token, reasoning token, cached token, dan biaya pada level response. Data seperti ini sebaiknya dicatat ke log atau tabel internal. Setelah itu, pola pemborosan akan terlihat lebih jujur. Mungkin ternyata agent reviewer terlalu sering membaca seluruh repo. Mungkin model besar dipakai untuk menulis dokumentasi sederhana. Mungkin log test mendominasi input. Mungkin prompt caching tidak efektif karena prefix selalu berubah.
Tanpa pengukuran, optimasi hanya terasa pintar di obrolan, tapi lemah di dashboard.
Kalau diringkas, arsitektur agent yang hemat biasanya punya pola seperti ini: satu orchestrator memahami tujuan, lalu memutuskan apakah tugas sebaiknya diarahkan ke tool deterministik, model kecil, model menengah, atau model besar. Hasil dari tool dipangkas, diringkas, dan hanya bagian penting yang masuk ke model. Sub-agent dipakai bila benar-benar memberi manfaat. Pada akhir alur, hasil diverifikasi dan usage dicatat. Pendekatannya mungkin terdengar sederhana, tetapi justru di situlah kekuatannya. Hemat token lahir dari disiplin kecil yang dilakukan berulang.
Berikut checklist praktis yang bisa langsung dipakai saat menyiapkan workflow agent:
- Pastikan file bootstrap singkat dan hanya berisi aturan inti.
- Definisikan ruang lingkup task dengan jelas sebelum agent mulai mencari.
- Batasi pencarian ke folder, simbol, atau file yang relevan.
- Kirim potongan file atau rentang baris, bukan isi file penuh jika tidak perlu.
- Pangkas output terminal dan test sebelum masuk ke model.
- Gunakan model murah untuk tugas rutin dan model besar untuk keputusan kompleks.
- Pilih tool deterministik atau codemod bila pekerjaan tidak butuh penalaran.
- Gunakan sub-agent hanya jika ada pembagian tanggung jawab yang tegas.
- Simpan shared memory sebagai ringkasan padat, bukan dump data.
- Kompres sesi panjang setelah membuat checkpoint yang jelas.
- Ringankan heartbeat dan pekerjaan berkala dengan konteks minimal.
- Catat biaya per request, per task, dan per model agar optimasi berbasis data.
Di balik semua teknik ini ada satu prinsip besar: AI agent yang efisien bukan agent yang selalu membaca paling banyak atau selalu memakai model paling mahal. Agent yang efisien tahu kapan harus berpikir dalam, kapan cukup mencari, kapan memakai tool biasa, dan kapan justru tidak perlu memanggil model sama sekali. Semakin matang context engineering Anda, semakin kecil peluang tagihan membesar diam-diam.
Jadi, kalau AI agent Anda sudah makin pintar, bagus sekali. Tinggal pastikan kebiasaannya juga makin hemat. Biar yang membesar itu kualitas hasil kerja, bukan angka di invoice.
Sumber resmi yang dapat ditelusuri:
- OpenClaw - Token Use and Costs: https://docs.openclaw.ai/reference/token-use
- OpenClaw - Agent Configuration dan Context Injection: https://docs.openclaw.ai/gateway/config-agents
- OpenClaw - Sub-agents: https://docs.openclaw.ai/tools/subagents
- OpenClaw - Heartbeat Configuration: https://docs.openclaw.ai/gateway/heartbeat
- OpenClaw - Session Management dan Compaction: https://docs.openclaw.ai/reference/session-management-compaction
- Hermes Agent - Dokumentasi utama: https://hermes-agent.nousresearch.com/docs/
- Hermes Agent - Configuration dan Context Limits: https://hermes-agent.nousresearch.com/docs/user-guide/configuration
- Hermes Agent - Persistent Memory: https://hermes-agent.nousresearch.com/docs/user-guide/features/memory
- Hermes Agent - Context References: https://hermes-agent.nousresearch.com/docs/user-guide/features/context-references
- Ruflo - Repository resmi: https://github.com/ruvnet/ruflo
- Ruflo - Panduan routing, codemod, booster, dan swarm: https://github.com/ruvnet/ruflo/blob/main/CLAUDE.md
- Ruflo - Wiki: https://github.com/ruvnet/ruflo/wiki
- OpenRouter - Usage Accounting: https://openrouter.ai/docs/cookbook/administration/usage-accounting
- OpenRouter - Delegasi task ke model lebih murah: https://openrouter.ai/docs/cookbook/building-agents/subagent-server-tool
- OpenRouter - Analytics dan Cost Control: https://openrouter.ai/docs/cookbook/administration/analytics-cost-control