Hemat Token LLM 2026: Prompt Caching dan 5 Cara Lain Pangkas Biaya AI Agent

Minggu pertama tagihan agent lo kecil. Minggu keempat sudah tiga kali lipat, padahal jumlah user-nya belum berubah banyak. Yang bertambah biasanya bukan user, tapi kelipatan token yang dikirim ulang di setiap request: system prompt panjang, definisi tool, hasil retrieval, plus riwayat percakapan yang ikut menumpuk.

Ada dua hal yang membuat ini bisa dipangkas secara teknis, bukan dengan menaikkan harga ke pelanggan: prompt caching dan disiplin context. Artikel ini pakai angka tarif yang gue baca langsung dari katalog model hari ini, jadi lo bisa hitung ulang dengan model apa pun yang lo pakai.

TL;DR

• Prompt caching memotong harga token input yang berulang. Di gateway yang gue pakai, input Rp150 per juta token jadi Rp30 per juta token saat dibaca dari cache, turun 80%.
• Untuk agent dengan system prompt 8.000 token dan 10.000 request per bulan, selisihnya sekitar Rp9.600 per bulan hanya dari satu parameter.
• Caching tidak menolong kalau prefix-nya berubah tiap request. Urutan prompt menentukan apakah cache kena atau tidak.
• Output token biasanya lebih mahal dari input. Cap output lebih cepat berdampak daripada memangkas prompt.
• Model routing sering memberi penghematan terbesar dan paling sepele: selisih model termurah dan termahal di satu katalog bisa lebih dari 200 kali.

Hitungan dasar: dari mana biaya agent datang

Satu request ke model punya tiga komponen yang dibayar:

1. Input token yang dikirim (system prompt, tool schema, riwayat, hasil retrieval, pertanyaan user).
2. Output token yang dihasilkan model.
3. Cache write dan cache read kalau provider mendukung caching.

Tarifnya per 1 juta token, dan biasanya output 2 sampai 5 kali lebih mahal dari input. Contoh dari katalog yang gue cek hari ini: satu model bertarif Rp150 input dan Rp300 output per juta token, model lain Rp181 input dan Rp907 output. Jadi memangkas setengah output tidak sama nilainya dengan memangkas setengah input.

Contoh kasus nyata yang gampang dihitung: agent customer service dengan system prompt plus tool schema 8.000 token, 10.000 request per bulan, rata-rata output 300 token, model Rp150 input / Rp300 output.

• Input tanpa caching: 10.000 x 8.000 = 80 juta token, biayanya 80 x Rp150 = Rp12.000
• Output: 10.000 x 300 = 3 juta token, biayanya 3 x Rp300 = Rp900
• Total tanpa caching: sekitar Rp12.900 per bulan

Angkanya terlihat kecil karena modelnya murah dan volumenya masih 10 ribu. Naikkan volumenya ke 200.000 request dengan model Rp3.627 input dan Rp18.133 output, dan urutannya berubah jadi puluhan juta rupiah per bulan. Strukturnya tetap sama: input mendominasi kalau prompt lo gemuk, output mendominasi kalau prompt lo ringkas tapi jawabannya panjang.

Prompt caching: cara kerjanya, versi jujur

Prompt caching menyimpan hasil komputasi untuk bagian prompt yang identik dan berurutan di awal. Request berikutnya yang mengirim prefix yang sama tidak perlu membayar ulang harga penuh; provider menagih tarif cache read yang jauh lebih murah.

Tiga hal yang perlu lo tahu sebelum berharap banyak:

1. Yang di-cache adalah prefix, bukan “isi prompt yang mirip”. Kalau system prompt lo sama persis di 8.000 token pertama, itu yang murah. Begitu ada satu baris tanggal hari ini di baris pertama, seluruh prefix jadi baru.
2. Cache punya masa hidup. TTL-nya beda per provider, ada yang hitungan menit, ada yang jam. Trafik yang datang bergerombol lebih beruntung daripada trafik yang tersebar rata seharian.
3. Cache write pun tidak gratis. Ada tarif tersendiri, biasanya di bawah harga input penuh tapi di atas nol. Kalau prefix lo panjang tapi cuma dipakai sekali, caching justru bisa lebih mahal.

Dengan tarif cache read Rp30 dan input Rp150 per juta token, contoh di atas berubah:

• Input dari cache: 80 juta token x Rp30 = Rp2.400
• Output tetap: Rp900
• Total: Rp3.300 per bulan, dari sebelumnya Rp12.900

Selisihnya Rp9.600 hanya dari satu pengaturan. Kalau provider lo menaruh cache write di harga yang wajar, titik impasnya biasanya tercapai di request kedua atau ketiga untuk prefix yang sama.

Urutan prompt menentukan segalanya

Pola yang berhasil di produksi hampir selalu seperti ini:

• Statis di depan: instruksi sistem, definisi tool, gaya jawaban, daftar kategori. Tidak boleh ada timestamp, nama user, atau ID request di sini.
• Setengah statis di tengah: dokumen referensi atau hasil retrieval. Kalau bisa diurutkan supaya dokumen yang paling sering muncul ada di depan, cache jadi lebih sering kena.
• Dinamis di belakang: pertanyaan user, hasil tool call terbaru, data sesi.

Kesalahan paling umum: menaruh “Sekarang jam 14:32” di baris kedua system prompt. Itu satu baris yang membatalkan cache untuk seluruh prefix di bawahnya, setiap request, selamanya.

Empat kegagalan caching yang sering kejadian

1. Prefix berubah tiap request. Timestamp, UUID, atau urutan tool schema yang tidak stabil (karena dibangun dari dictionary tanpa urutan) membuat cache miss 100%.
2. Prompt dipecah jadi beberapa request kecil. Caching menghargai prefix panjang yang dipakai berulang, bukan banyak request pendek.
3. Cache dianggap pengganti desain prompt. Kalau prompt lo 40.000 token karena berisi dokumen yang tidak relevan, caching cuma membuat kesalahan itu lebih murah, bukan benar.
4. Tidak ada observability. Tanpa mencatat persentase request yang kena cache, lo tidak akan pernah tahu caching-nya jalan atau cuma ada di dokumen arsitektur.

Lima lever biaya lain, urut dari yang paling cepat

1. Model routing

Selisih tarif antar model di satu katalog bisa ekstrem. Dari katalog yang gue baca hari ini: kelas termurah Rp78 input dan Rp264 output per juta token, kelas tertinggi Rp18.133 input dan Rp90.664 output. Rasionya lebih dari 200 kali. Routing pertanyaan sederhana (klasifikasi, ekstraksi, format ulang) ke model murah, dan hanya pertanyaan yang butuh penalaran panjang ke model mahal, biasanya memotong tagihan lebih besar daripada semua trik prompt digabung.

2. Cap output token

Output hampir selalu lebih mahal dari input per token. Batas atas output yang eksplisit mencegah model menulis esai saat lo minta satu baris. Ini juga memotong latensi.

3. Pangkas context, jangan cuma andalkan window besar

Window 1 juta token bukan undangan untuk mengisinya. Riwayat percakapan yang tumbuh tanpa ringkasan adalah biaya yang naik linear terhadap panjang sesi. Ringkas tiap N giliran, simpan fakta kunci, buang percakapan yang sudah selesai.

4. Batch pekerjaan yang tidak butuh jawaban instan

Pekerjaan seperti klasifikasi arsip, rekap harian, atau audit konten tidak butuh respons 300 milidetik. Mengelompokkannya dalam satu job mengurangi overhead per request dan memungkinkan pemakaian tarif batch kalau provider menyediakannya.

5. Instrumentasi biaya per fitur

Tanpa angka per fitur, optimasi jadi tebak-tebakan. Catat minimal empat hal per request: model, token input, token output, dan apakah kena cache. Empat kolom itu cukup untuk menemukan fitur mana yang menghabiskan 80% budget.

Kesalahan yang bikin semua usaha di atas sia-sia

• Mengoptimasi prompt yang dipanggil 20 kali sehari, sementara satu job bulanan menghabiskan 90% budget.
• Menghapus caching karena “kelihatan tidak ngefek”, tanpa pernah mengukur hit rate.
• Memakai model mahal untuk tugas yang jawabannya cuma perlu satu kata: ya atau tidak.
• Menyimpan seluruh dokumen di system prompt supaya “modelnya tahu banyak”, lalu heran tagihannya naik.
• Tidak memasang alarm. Lonjakan biaya biasanya ketahuan dari tagihan, bukan dari dashboard.

Urutan kerja yang gue sarankan

1. Nyalakan pencatatan token per fitur selama satu minggu. Jangan optimasi apa pun sebelum ada angka.
2. Urutkan fitur berdasarkan biaya total, bukan biaya per request. Fitur murah yang dipanggil sejuta kali lebih penting daripada fitur mahal yang dipanggil sepuluh kali.
3. Untuk fitur teratas, cek dulu apakah prefix-nya stabil. Kalau tidak stabil, rapikan urutan prompt sebelum bicara caching.
4. Pasang routing model untuk tugas yang tidak butuh penalaran.
5. Cap output untuk semua endpoint yang jawabannya bisa dibatasi.
6. Baru setelah itu ukur ulang dan bandingkan.

Kalau agent lo masih di tahap memilih arsitektur, urutan ini nyambung dengan OpenCrabs vs n8n vs LangChain: keputusan platform menentukan seberapa mudah biaya per fitur bisa diukur sama sekali.

Kesimpulan

Prompt caching itu nyata dan bisa dihitung: input Rp150 per juta token jadi Rp30 saat dibaca dari cache. Tapi penghematan terbesar hampir selalu datang dari keputusan yang lebih membosankan: model yang tepat untuk tugas yang tepat, output yang dibatasi, dan context yang tidak dibiarkan tumbuh tanpa kendali.

Mulai dari satu angka: berapa token input rata-rata per request di fitur paling mahal lo. Kalau angkanya di atas 10.000, di situ ada uang.