Prompt caching adalah mekanisme penetapan harga yang ditawarkan sejumlah penyedia AI: konten yang berulang kali kamu kirim (system prompt, definisi tool, deskripsi latar belakang proyek) disimpan sementara, jadi saat konten yang sama persis muncul lagi, kamu hanya dikenakan tarif "cache read" yang lebih murah, bukan tarif "input" penuh. Namun menulis ke cache juga tidak gratis — jika prefiks kontenmu kurang stabil atau hit rate-nya terlalu rendah, biaya penulisan bisa lebih besar dari penghematan pembacaan, dan totalnya malah membuat tagihanmu naik, bukan turun. Inilah temuan yang berlawanan dengan intuisi dari pengujian sistematis 5 strategi manajemen konteks oleh kanal YouTube Atef Ataya.
Artikel ini akan membahas: apa yang sebenarnya dihemat oleh caching, dalam kondisi apa caching justru menjadi beban, dan — di luar caching — urutan penghematan yang lebih mendasar yang layak dipertimbangkan lebih dulu.
Sebenarnya apa yang di-cache oleh prompt caching?
Kebanyakan API LLM memecah satu panggilan menjadi "input token" dan "output token" dengan harga terpisah, dan caching lebih jauh memecah sisi input menjadi dua kondisi: cache write (cache creation) dan cache read. Saat suatu konten tetap dikirim untuk pertama kali, sistem harus menyimpannya, dan biaya ini biasanya sama atau lebih tinggi dari harga input normal. Setelah itu, setiap kali konten yang sama persis muncul lagi di bagian paling depan permintaan, sistem langsung mengenai cache dan mengenakan tarif "read" yang jauh lebih rendah.
Dengan kata lain, caching bukan menghemat "konten itu sendiri" — yang dihemat adalah "pengulangan". Jika suatu konten selalu berbeda di setiap panggilan, cache tidak akan pernah kena, dan kamu sudah membayar biaya penulisan untuk diskon yang tidak akan pernah kamu dapat.
Cache sebaiknya ditaruh di mana? Prefiks stabil vs. data tugas
Pengujian ini secara khusus menekankan satu aturan urutan: taruh konten yang tidak pernah berubah di bagian paling depan permintaan — seperti aturan sistem, definisi tool, deskripsi tetap proyek atau codebase — lalu taruh data yang berubah di setiap panggilan setelahnya. Logikanya sederhana: caching bekerja dengan mencocokkan apakah prefiks sama persis karakter demi karakter. Begitu ada satu karakter di depan yang berbeda, bagian setelahnya tidak bisa diselamatkan meskipun isinya sama. Mencampur konten yang mudah berubah di depan konten stabil sama saja dengan sengaja memutus rantai cache-mu sendiri.
Sebaliknya, jika suatu proyek memang sedikit definisi tool-nya dan deskripsi latar belakangnya sering ditulis ulang setiap tugas, "prefiks stabil" yang bisa dipegang cache akan pendek dari awal — dan manfaat mengaktifkan caching pun sudah terbatas sejak awal.
Kenapa volume cache read turun tapi tagihan malah naik?
Ini bagian paling berlawanan dengan intuisi dari seluruh pengujian. Dalam eksperimen di mana caching ditambahkan secara manual, volume "input yang di-cache" memang turun sekitar 15%—kedengarannya seharusnya menghemat—tapi biaya total justru naik sekitar 7%. Alasannya: penghematan dari lebih sedikit pembacaan habis dimakan oleh overhead yang ditimbulkan oleh cache read itu sendiri. Saat hit rate tidak stabil dan prefiks terus-menerus terputus, sistem terpaksa terus menulis ulang cache dan terus memicu permintaan pembacaan, dan pembacaan-pembacaan kecil yang tercecer ini menumpuk hingga melebihi apa yang seharusnya dihemat.
Ini juga menjelaskan mengapa caching bukan fitur yang "begitu diaktifkan pasti hemat" — melainkan soal harga yang sangat bergantung pada pola penggunaanmu: hit rate yang tinggi dan stabil membuat biaya penulisan layak dibayar demi diskon pembacaan; hit rate yang rendah membuat biaya penulisan yang sama berubah menjadi beban tambahan semata.
Bagaimana memilih waktu penyimpanan cache (TTL)?
Kebanyakan API yang menawarkan prompt caching membiarkan pengguna memilih berapa lama cache disimpan—makin lama disimpan, biasanya kamu membayar biaya penulisan dengan kelipatan yang lebih tinggi, sebagai gantinya kamu punya jendela waktu lebih lama untuk terus mendapat diskon. Ini pada dasarnya pertukaran risiko: jika kamu yakin akan sering memanggil prefiks yang sama berulang kali dalam waktu dekat, TTL yang lebih panjang akan menguntungkan; tapi jika frekuensi panggilanmu tidak cukup tinggi, atau prefiksnya bisa berubah di tengah jalan, biaya penulisan ekstra yang kamu bayar mungkin tidak pernah balik modal.
⚠️ Perlu dijelaskan secara khusus: video ini menyebutkan bahwa API Claude saat ini mengungkap penggunaan cache melalui dua kolom terpisah — "cache write token" dan "cache read token" — dan menawarkan dua tingkat TTL untuk dipilih (tingkat yang lebih singkat memakai harga cache standar, tingkat yang lebih panjang dikenakan kelipatan). Ini menggambarkan cara video aslinya menjelaskan mekanismenya; durasi tingkat yang sebenarnya dan kelipatan tarifnya sebaiknya diverifikasi terhadap halaman harga resmi Anthropic saat ini, bukan hanya bergantung pada penjelasan satu video saja.
Langkah yang lebih perlu dilakukan sebelum caching: bukan memuat lebih pintar, tapi sejak awal tidak memuat sama sekali
Pengujian ini membandingkan 5 cara menurunkan biaya konteks, dan yang menempati posisi pertama—efeknya paling besar dan paling konsisten—bukanlah bentuk caching apa pun atau teknik pencarian yang lebih pintar, melainkan langkah paling sederhana: sebelum menangani tugas, tentukan secara eksplisit file atau data mana saja yang benar-benar "dibutuhkan", dan jangan baca yang lain sama sekali. Cara ini menurunkan volume data yang dikirim ke model cukup besar, sehingga biaya total sekitar 30% lebih rendah dari skenario dasar tanpa melakukan apa-apa, dan menjadi satu-satunya strategi yang konsisten menghemat biaya di setiap putaran pengujian berulang.
Logika di baliknya sederhana: caching dan pengindeksan terstruktur pada dasarnya membuat "pemuatan" jadi lebih efisien, tapi model tetap dikenakan biaya untuk setiap token yang dimuat; sementara menyaring dan mengecualikan data yang tidak relevan lebih dulu berarti sebagian token memang tidak pernah dikirim sama sekali—uang ini benar-benar tidak pernah dikeluarkan. Token paling murah adalah token yang sejak awal tidak pernah dikirim ke dalam permintaan.
"Muat hanya saat dibutuhkan" kedengarannya paling masuk akal—kenapa pengujian justru menunjukkan ini strategi paling mahal?
Intuisi umum lainnya adalah mulai dengan konteks paling minim, ambil apa yang dibutuhkan saat diperlukan, dan buang setelah dipakai—kedengarannya seperti pendekatan paling hemat sumber daya, tapi dalam pengujian ini justru menjadi strategi dengan biaya tertinggi, hampir 45% lebih mahal dari skenario dasar.
Masalahnya ada pada mekanisme penagihan: kebanyakan API LLM mengenakan biaya per permintaan penuh, dan setiap permintaan harus mengirim ulang seluruh riwayat percakapan yang terakumulasi sampai saat itu. "Buang setelah dipakai" hanya membuat model "melupakan" isi suatu file—tidak membuat file itu hilang dari tagihan. Jika suatu tugas perlu memeriksa puluhan file satu per satu, itu berarti puluhan permintaan bolak-balik, dan setiap bolak-balik harus menyertakan ulang seluruh isi percakapan sebelumnya. Strategi yang dirancang untuk "meringkas" konteks justru berujung menjadi strategi yang paling banyak mengirim ulang konteks yang sama. Ini juga peringatan khusus yang disebutkan dalam pengujian: arah optimasi manajemen konteks harus melihat total token yang dikirim di seluruh tugas, bukan seberapa "bersih" satu permintaan terlihat.
Kenapa menumpuk semua trik penghematan sekaligus justru lebih mahal daripada tidak melakukan apa-apa?
Menggabungkan berbagai strategi manajemen konteks di atas secara bersamaan adalah yang biasanya disarankan secara default oleh banyak panduan, tapi hasil pengujian menunjukkan biaya total dari kombinasi penuh ini sekitar 23% lebih tinggi dari skenario dasar tanpa melakukan apa-apa—lebih buruk daripada memakai satu strategi saja secara terpisah.
Alasannya: berbagai strategi saling bertabrakan, bukan saling menambah. Misalnya, melakukan dua jenis analisis struktural berbeda secara bersamaan menghasilkan overhead analisis ganda; sementara caching dan "muat hanya saat dibutuhkan" dibangun di atas asumsi penggunaan yang saling bertentangan (satu mengasumsikan prefiks stabil dan berulang, yang lain mengasumsikan konten tercecer dan sering berubah). Mengaktifkan keduanya sekaligus hanya menumpuk biaya setup tambahan tanpa penghematan yang setara. Melakukan lebih banyak tidak sama dengan lebih hemat—setiap strategi punya biaya aktivasi sendiri, dan menumpuk lebih banyak strategi hanya menaikkan ambang batas yang harus dilewati sebelum semuanya benar-benar terbayar.
Dalam situasi apa mengaktifkan caching benar-benar layak? Satu urutan keputusan
Merangkum semua temuan di atas, berikut urutan prioritas kasar untuk mengevaluasi situasi penggunaanmu sendiri:
1. Saring dulu, baru cache —sebelum menangani tugas, tentukan dengan jelas data apa saja yang benar-benar dibutuhkan tugas ini, dan langsung kecualikan bagian yang tidak relevan dari permintaan. Ini adalah langkah dengan efek terbesar dan paling konsisten. 2. Kedua, beri model peta struktur yang ringan —gunakan direktori ringkas atau deskripsi hubungan dependensi, agar model tidak perlu mengandalkan pembacaan coba-coba untuk menemukan konten yang dibutuhkan. 3. Caching ditempatkan setelah keputusan arsitektur, diperlakukan murni sebagai soal harga —konfirmasi dulu apakah pola penggunaanmu memang punya prefiks yang "stabil dan dipanggil berulang", jika ada, baru layak mengaktifkan caching untuk itu; jika konten sering berubah dan frekuensi panggilan tidak tinggi, mengaktifkan caching bisa jadi hanya menambah satu biaya penulisan. 4. Pendekatan pencarian "muat hanya saat dibutuhkan" ditempatkan paling akhir —hanya layak dipertimbangkan saat volume data kandidat sangat besar dan bagian yang benar-benar dibutuhkan hanya sebagian kecil saja; selain itu, sifat penagihan per permintaan dan pengiriman ulang riwayat percakapan membuatnya sangat mudah menjadi opsi paling mahal.
Logika bersama di balik urutan ini: selesaikan dulu "apakah data ini perlu dikirim sama sekali", baru selesaikan "apakah pengirimannya bisa dibuat lebih murah". Caching menyelesaikan yang kedua—jika yang pertama belum ditangani dengan baik, ruang yang bisa dimanfaatkan caching pun sudah terbatas dari awal.
FAQ
T1: Apa itu prompt caching, dan apa bedanya dengan harga panggilan API biasa?
Harga biasa hanya membagi token menjadi "input" dan "output". Setelah caching diaktifkan, sisi input dipecah lagi menjadi kondisi "cache write" dan "cache read"; konten tetap yang muncul pertama kali dikenakan biaya penulisan, dan saat konten yang sama persis muncul lagi tanpa berubah, dikenakan tarif pembacaan yang lebih rendah.
T2: Kalau saya mengaktifkan prompt caching, apakah tagihan pasti jadi lebih murah?
Belum tentu. Jika prefiks konten yang dikirim kurang stabil, atau jumlah hit berulangnya tidak cukup banyak, biaya penulisan cache yang kamu bayar bisa melebihi penghematan dari diskon pembacaan—pengujian ini sendiri menemukan kasus di mana volume cache read menurun tapi biaya total malah naik.
T3: Konten tugas saya sering berubah-ubah, apakah cocok mengaktifkan caching?
Jika data tugas selalu berbeda setiap kali, tanpa prefiks tetap yang tidak berubah, caching hampir tidak punya apa pun yang stabil untuk dipegang, dan manfaatnya dalam situasi seperti ini biasanya terbatas. Urutan prioritas sebaiknya diletakkan pada menyaring dulu data mana yang benar-benar dibutuhkan, bukan langsung terburu-buru mengaktifkan caching.
T4: Sebaiknya pilih TTL yang pendek atau panjang?
Bergantung pada seberapa tinggi frekuensi kamu akan memanggil ulang prefiks yang sama dalam waktu dekat. TTL yang lebih panjang biasanya berarti kelipatan biaya penulisan yang lebih tinggi juga, jadi hanya layak jika kamu memperkirakan akan ada banyak hit berulang dalam jendela waktu singkat; periksa tingkatan dan kelipatan tarif sebenarnya pada halaman harga resmi penyedia yang berlaku saat itu.
T5: Selain caching, apa saja cara lain untuk menurunkan biaya token AI Agent?
Pengujian menunjukkan bahwa menyaring secara eksplisit "data apa yang benar-benar dibutuhkan tugas ini" sebelum mulai adalah langkah dengan efek terbesar dan paling konsisten; kedua adalah menyediakan peta struktur ringan untuk model agar tidak banyak melakukan pembacaan coba-coba. Keduanya ditempatkan sebelum caching, karena keduanya mengurangi "apakah data itu dikirim sama sekali"—sementara caching hanya bisa mengoptimalkan "seberapa murah pengirimannya".
T6: Apakah data pengujian di artikel ini dijalankan menggunakan Claude?
Pengujian aslinya menjalankan lima putaran berulang menggunakan tarif publik dari penyedia model lain (DeepSeek), khusus untuk memastikan perbandingan berfokus pada "rasio biaya antar strategi konteks yang berbeda", bukan angka absolut dari satu penyedia tertentu. Video ini secara terpisah menjelaskan cara kerja umum mekanisme caching pada API Claude (token cache write/read serta tingkatan TTL). Kesimpulan metodologisnya—bahwa manfaat caching bergantung pada hit rate dan stabilitas prefiks, serta bahwa menyaring dulu lebih baik daripada langsung caching—tidak spesifik untuk satu penyedia tertentu, tapi untuk angka pasti harga resmi Claude, tetap perlu diperiksa langsung pada pengumuman resmi Anthropic yang berlaku saat ini.
Catatan sumber
Artikel ini merujuk pada video *"I Tested Claude's Prompt Cache. It Cost Me More."* dari kanal Atef Ataya, tautan asli: https://www.youtube.com/watch?v=DyzDuiwISa8. Angka perubahan biaya untuk setiap strategi manajemen konteks yang dibahas di sini (caching, peta struktur, grafik dependensi, penyaringan data, pencarian sesuai kebutuhan, dan sebagainya) disusun berdasarkan metodologi pengujian dan kesimpulan yang dijelaskan dalam video tersebut. Pengujian itu sendiri menggunakan tarif publik dari penyedia model lain sebagai basis perbandingan yang seragam, dan video secara eksplisit menyatakan bahwa fokus perbandingannya adalah rasio biaya antar strategi, bukan angka absolut dari penyedia tertentu. Untuk bagian yang menyangkut detail mekanisme cache pada API Claude secara spesifik (tingkatan TTL, kelipatan tarif), pembaca disarankan memeriksa secara mandiri dokumentasi harga resmi Anthropic yang berlaku saat ini untuk mendapatkan angka yang akurat dan terkini.
Baca juga
Tagihan AI yang Menakutkan Itu Ternyata Sebuah Cermin
Ingin lebih memahami biaya token AI kamu secara lebih jelas?
Baik kamu sedang memutuskan apakah prompt caching layak diaktifkan, atau hanya ingin tahu berapa banyak token yang benar-benar terbakar dari alur kerja Agent-mu setiap bulan, AI Token King membantu merangkum data pemakaian dan biaya yang tercecer di berbagai penyedia model ke dalam satu dashboard yang mudah dibaca dan dilacak.
