Prompt Caching: Hemat Berapa dan Kapan Malah Rugi

Kalau aplikasimu mengirim instruksi sistem yang sama berulang-ulang — dan hampir semua aplikasi begitu — caching adalah satu perubahan yang bisa memotong tagihan input sampai tinggal sepersekian.

Tapi dia tidak gratis. Menulis cache lebih mahal daripada input biasa, jadi ada titik di mana dia menghemat dan titik di mana dia menambah biaya. Tulisan ini menghitung keduanya.

Angkanya di Claude

	Sonnet 5.5	Opus 5.5
Input biasa	$2	$4
Tulis cache 5 menit	$2,50	$5
Tulis cache 1 jam	$4	$8
Baca cache (hit)	$0,10	$0,20

Per satu juta token, dicek 27 Oktober 2026.

Dua angka yang perlu dibaca bersamaan:

Membaca cache cuma 5% harga input biasa. Itu potongan 95% untuk bagian prompt yang berulang — bukan penghematan kecil.

Menulis cache lebih mahal daripada input biasa. Yang 5 menit 1,25 kali tarif input, yang 1 jam dua kali tarif input. Jadi kamu membayar premi di awal untuk mendapat tarif murah di permintaan berikutnya.

OpenAI punya mekanisme serupa dengan tarif cached input yang juga jauh di bawah input biasa — angkanya di artikel harga API.

Titik impasnya: lebih cepat dari dugaan

Pakai Sonnet 5.5 dan satu blok prompt sebesar 1 juta token sebagai satuan hitung.

Tanpa cache, mengirimnya N+1 kali: (N+1) × $2.

Dengan cache 5 menit, sekali tulis lalu N kali baca: $2,50 + (N × $0,10).

Jumlah pemakaian	Tanpa cache	Cache 5 menit
1× (tulis saja, tidak dibaca lagi)	$2,00	$2,50 — rugi
2× (1 tulis + 1 baca)	$4,00	$2,60 — hemat 35%
5×	$10,00	$2,90 — hemat 71%
20×	$40,00	$4,40 — hemat 89%

Impasnya di pemakaian kedua. Begitu bagian prompt itu dipakai lebih dari sekali dalam jendela cache, caching sudah lebih murah — dan selisihnya melebar cepat.

Untuk cache 1 jam yang premi tulisnya dua kali lipat, impasnya di pemakaian ketiga: $4 + 2 × $0,10 = $4,20 dibanding $6 tanpa cache.

Kesimpulan praktisnya: cache 5 menit hampir selalu layak untuk apa pun yang berulang. Cache 1 jam baru masuk akal kalau jeda antar permintaan memang lebih dari lima menit — misalnya pengguna yang membaca dulu sebelum bertanya lagi.

Kapan caching malah menambah biaya

Tiga kasus, dan semuanya nyata:

Prompt yang cuma dipakai sekali. Tugas sekali jalan, tanpa pengulangan. Kamu membayar premi tulis tanpa pernah menikmati tarif bacanya.

Prompt yang isinya berubah tiap permintaan. Kalau bagian awal prompt memuat sesuatu yang berbeda tiap kali — timestamp, nama pengguna, ID permintaan — maka tidak ada bagian yang “sama persis”, dan cache tidak pernah kena. Kamu membayar premi tulis berulang kali tanpa satu pun hit.

Jeda yang melewati durasi cache. Cache 5 menit yang baru dipakai lagi sepuluh menit kemudian sudah kedaluwarsa. Kamu menulis ulang, membayar premi lagi.

Cara menyusun prompt supaya kena tarif murah

Aturannya satu dan sederhana: yang tetap di depan, yang berubah di belakang.

Susunan yang benar:

1. Instruksi sistem — tidak pernah berubah
2. Dokumen rujukan atau contoh — jarang berubah
3. Riwayat percakapan — bertambah
4. Pertanyaan baru — berubah tiap kali

Susunan yang membuang uang: menaruh timestamp, ID sesi, atau nama pengguna di awal prompt. Satu baris yang berubah di posisi pertama membatalkan kecocokan seluruh blok sesudahnya.

Ini kesalahan yang mudah terjadi karena terasa rapi — “mari taruh metadata di atas”. Di sistem penagihan ini, metadata di atas berarti nol cache hit selamanya.

Memperkirakan hematnya untuk aplikasimu

Hitungan kasar yang cukup akurat:

(token prompt tetap) × (jumlah permintaan − 1) × (harga input − harga cache hit)

Contoh: instruksi sistem 3.000 token, 1.000 permintaan sebulan, Sonnet 5.5.

• Tanpa cache: 3.000 × 1.000 = 3 juta token input → $6
• Dengan cache: tulis sekali-sekali plus 3 juta token kena tarif hit → mendekati $0,30

Penghematan sekitar $5,70 sebulan dari satu perubahan susunan prompt. Angkanya kecil di skala ini, tapi dia tumbuh lurus dengan jumlah permintaan — di 100 ribu permintaan, selisihnya ratusan dolar.

Yang perlu diukur, bukan diasumsikan

Caching menghemat kalau cache-nya benar-benar kena. Jangan menganggap sudah kena hanya karena kamu sudah menyusun prompt dengan benar — respons API umumnya melaporkan berapa token yang terbaca dari cache. Periksa angka itu di permintaan kedua. Kalau nol, ada sesuatu di awal prompt yang berubah tanpa kamu sadari.

Satu pengukuran lima menit di awal lebih berharga daripada optimasi berminggu-minggu di bagian yang salah.

Cara menekan biaya token selain caching — pemilihan model, Batch API, memangkas riwayat — ada di artikel token. Kalau kamu belum memutuskan antara API dan langganan, hitungannya ada di langganan Claude Pro atau API.