Mengaktifkan prompt caching tidak memberikan penghematan apa pun bagi saya—bahkan, tagihan OpenAI-API saya melonjak sekitar seperempatnya. Penyebabnya adalah satu baris yang berubah pada setiap permintaan: timestamp yang tertanam dalam system prompt.

Penyedia LLM mengizinkan pengembang untuk melakukan caching pada fragmen prompt guna memangkas biaya pemrosesan token. Pembacaan cache (sebuah “hit”) biayanya hanya sepersepuluh dari tarif reguler, sementara penulisan cache (sebuah “miss”) biayanya sekitar 1,25 × harga normal. Jika penulisan terjadi tetapi fragmen yang di-cache tidak pernah dibaca, biaya tambahan 25% tersebut terbuang percuma. Itulah yang terjadi ketika timestamp membuat prompt tidak cocok dengan entri cache yang sudah ada.

Mengapa caching bisa berakibat buruk

Prompt caching bekerja dengan mencocokkan urutan byte yang persis dari bagian yang di-cache. Penyedia melakukan hashing pada input; jika hash tersebut cocok dengan entri yang tersimpan, sistem akan menggunakan kembali komputasi sebelumnya dan menerapkan tarif baca yang murah. Variasi apa pun—bahkan satu karakter sekalipun—akan merusak kecocokan tersebut dan memaksa komputasi baru, yang ditagih dengan tarif tulis yang lebih tinggi.

Dalam kasus saya, system prompt dimulai dengan:

Current session started: 2026-07-14T09:41:07Z

Karena timestamp diperbarui untuk setiap panggilan API, beberapa byte pertama dari permintaan tidak pernah identik. Penyedia memperlakukan setiap panggilan sebagai entri cache baru, mengenakan premi penulisan, dan tidak pernah mencatat pembacaan. Hasilnya adalah kenaikan terus-menerus pada cache_creation_input_tokens sementara cache_read_input_tokens tetap di angka nol, sebuah tanda jelas bahwa cache tidak pernah berhasil dipicu (hit).

Cara mendeteksi cache yang rusak

Log penggunaan yang disediakan oleh API memberikan dua penghitung utama:

  • cache_creation_input_tokens – token yang memicu penulisan.
  • cache_read_input_tokens – token yang mendapatkan manfaat dari pembacaan.

Ketika yang pertama melonjak dan yang terakhir tetap datar, cache tidak digunakan kembali. Pemeriksaan cepat yang bisa dilakukan adalah dengan mengulangi permintaan yang persis sama sebanyak dua kali; panggilan kedua harus menunjukkan lonjakan pada token baca jika cache berfungsi.

Memperbaiki masalah

Solusinya sederhana: pastikan bagian yang di-cache bersifat statis di seluruh panggilan. Ikuti dua aturan ini:

  1. Letakkan konten yang tidak dapat diubah (immutable) di awal. System prompt, definisi tool, atau instruksi apa pun yang tidak pernah berubah harus menempati byte awal dari permintaan.
  2. Tambahkan konten yang dapat berubah (mutable) di akhir. Timestamp, teks buatan pengguna, ID permintaan, atau data apa pun yang bervariasi per panggilan harus diletakkan setelah segmen yang di-cache.

Jika satu karakter saja bergeser, hash akan berubah dan cache miss akan terus terjadi. Menyusun ulang prompt sehingga timestamp berada di akhir akan memulihkan tingkat cache hit dan menurunkan tagihan kembali ke tingkat biaya rendah yang diharapkan.

Kapan caching benar-benar membantu

Prompt caching sangat berguna dalam skenario di mana set instruksi yang sama digunakan berulang kali:

  • Agent loops di mana AI berulang kali memanggil sekumpulan tool yang tetap.
  • Chat sessions yang merujuk pada dokumen statis yang panjang sementara hanya kueri terbaru pengguna yang berubah.
  • Bulk data extraction di mana prompt parsing yang sama diterapkan pada banyak catatan.

Untuk panggilan single-shot yang menyertakan konteks baru setiap saat—seperti pertanyaan sekali jalan dengan preamble unik—caching tidak memberikan manfaat dan bahkan dapat menambah biaya jika permintaan secara tidak sengaja memicu penulisan.

Jebakan tersembunyi

Meskipun prompt itu sendiri bersifat statis, permintaan dapat diubah di hilir:

  • Proxy atau agregator yang mengatur ulang urutan atau menyisipkan spasi dapat merusak kecocokan byte-per-byte.
  • Layanan gateway yang menambahkan header autentikasi di awal atau memodifikasi format JSON dapat secara tidak sengaja mengubah fragmen yang di-cache.

Melakukan pengujian melalui gateway dengan mengirimkan permintaan yang identik dua kali dan memeriksa penghitung baca membantu memverifikasi bahwa jalur caching tetap utuh.

Gambaran biaya yang lebih luas

Biaya tambahan 25% pada penulisan bukanlah penalti karena menggunakan caching; itu mencerminkan komputasi ekstra yang diperlukan untuk menyimpan fragmen tersebut demi penggunaan kembali di masa mendatang. Ketika cache hit terjadi, biayanya turun drastis—seringkali menjadi sebagian kecil dari tarif reguler. Kuncinya adalah membiarkan sistem benar-benar mengenai (hit) cache tersebut. Jika tidak, Anda membayar premi tanpa mendapatkan penghematan apa pun.

Argumen tandingan: caching belum mati

Beberapa pengembang berpendapat bahwa kompleksitas dalam mengelola bagian prompt statis versus dinamis lebih besar daripada penghematan yang didapat. Pandangan tersebut mengabaikan fakta bahwa banyak alur kerja produksi sudah memisahkan konfigurasi (statis) dari data pengguna (dinamis). Dengan menyusun prompt secara tepat, mekanisme caching yang sama yang menguntungkan pengembang asli API tersebut dapat dimanfaatkan tanpa upaya ekstra. Komprominya hanyalah sedikit disiplin dalam desain prompt, bukan cacat mendasar pada teknologinya.

Apa yang perlu diperhatikan selanjutnya

  • Pantau kedua penghitung cache di dasbor penggunaan Anda setiap minggu.
  • Audit konstruksi prompt untuk memastikan bahwa elemen variabel apa pun berada setelah blok yang di-cache.
  • Jalankan uji A/B dengan dan tanpa caching pada beban kerja yang representatif untuk mengukur penghematan yang sebenarnya.
  • Validasi gateway dengan membandingkan payload permintaan mentah sebelum dan sesudah penggunaan proxy apa pun.

Kesimpulan

Prompt caching dapat memangkas biaya API LLM, tetapi hanya jika segmen yang di-cache benar-benar identik di setiap panggilan. Timestamp yang terselip atau token dinamis lainnya di awal prompt akan memaksa penulisan yang mahal setiap saat, sehingga membengkakkan tagihan. Dengan menempatkan instruksi statis di bagian depan dan menempatkan data yang berubah di bagian akhir, Anda membiarkan cache bekerja secara optimal dan menjaga pengeluaran tetap terkendali.