LLM Prompt Caching: Optimasi Biaya Termurah yang Belum Anda Pakai

Waktu saya mengaudit tagihan token salah satu fitur AI saya awal tahun ini, pos biaya terbesar bukan bagian pintarnya produk. Melainkan mengirim ulang system prompt dan konteks dokumen 40K token yang sama di setiap request, dengan harga penuh, ratusan kali sehari. Prompt caching menyelesaikan itu dalam satu sore dan memangkas tagihan input sekitar 85 persen.

Semua provider besar kini punya bentuk prompt caching — Anthropic, OpenAI, dan Google Gemini semuanya — tetapi ekonomi dan ergonomi developernya cukup berbeda sehingga arsitektur prompt yang sama bisa nyaris gratis di satu platform dan harga penuh di platform lain. Tulisan ini membahas cara kerja tiga model caching itu, angka-angka aktualnya, dan aturan arsitektur prompt yang membuat caching andal, bukan kebetulan.

Cara Kerja Prompt Caching Sebenarnya

Ketiga provider mengimplementasikan ide inti yang sama: prefix match. Provider melakukan hash pada prompt yang dirender dari byte pertama ke depan, dan kalau request sebelumnya sudah memproses prefix yang identik, komputasi attention untuk rentang itu dipakai ulang alih-alih dihitung ulang. Konsekuensi yang menggerakkan semuanya: perubahan satu byte di mana pun dalam prefix membatalkan semua yang ada setelahnya. Timestamp yang diinterpolasi ke system prompt, key JSON yang berubah urutan di definisi tool, ID per-user di bagian atas — masing-masing diam-diam mematikan cache.

Anthropic membuat caching eksplisit: Anda menaruh breakpoint cache_control di blok stabil terakhir, dan konten dirender dengan urutan tools, lalu system, lalu messages. OpenAI melakukan cache otomatis tanpa perubahan kode untuk prompt 1.024 token atau lebih. Gemini memberi keduanya: implicit caching di Gemini 2.5 ke atas tanpa jaminan, dan objek cache eksplisit yang Anda buat dan bayar penyimpanannya saat ingin penghematan terjamin.

// Anthropic: explicit breakpoint on the stable prefix
const response = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 4096,
  system: [
    {
      type: "text",
      text: BIG_STABLE_SYSTEM_PROMPT, // frozen — no timestamps in here
      cache_control: { type: "ephemeral" }, // 5-minute TTL
    },
  ],
  messages: [{ role: "user", content: userQuestion }], // volatile part last
})

Ekonomi Caching Lintas Provider

Ini perbandingan yang penting saat Anda memutuskan di mana fitur bervolume tinggi akan tinggal. Angka dari dokumentasi resmi masing-masing provider per pertengahan 2026, tertaut di sumber bawah:

Merancang Prompt agar Ramah Cache

Caching menghargai disiplin yang seharusnya Anda punya dari dulu: memisahkan yang stabil dari yang berubah-ubah. Aturan yang sekarang saya terapkan di setiap fitur LLM, berurutan:

1. Bekukan system prompt. Tanpa timestamp, tanpa nama user, tanpa feature flag yang diinterpolasi ke dalamnya. Konteks dinamis masuk ke message berikutnya di mana ia tidak membatalkan apa pun di atasnya.
2. Urutkan konten berdasarkan stabilitas: definisi tool dan system prompt dulu, konteks sesi berikutnya, pertanyaan per-request paling akhir.
3. Serialisasi secara deterministik. Sortir key JSON, jangan pernah iterasi set ke dalam prompt, dan jaga daftar tool identik byte demi byte antar request — menambah atau mengubah urutan satu tool membangun ulang seluruh cache.
4. Taruh breakpoint di akhir bagian yang dibagikan, bukan akhir prompt. Kalau Anda menandai sufiks yang berubah-ubah, setiap request menulis entri cache baru dan tidak membaca apa pun.
5. Untuk agent multi-turn, majukan breakpoint ke giliran yang paling baru ditambahkan di tiap request, supaya seluruh prefix percakapan terakumulasi bertahap.

Para Pembatal Senyap

Saat pembacaan cache mendatar di nol, salah satu dari ini hampir selalu bersembunyi di jalur perakitan prompt:

• Pemanggilan datetime atau UUID request yang dirender di dekat puncak system prompt — prefix berubah setiap request.
• Serialisasi JSON non-deterministik, di mana urutan key berbeda antar proses atau deploy.
• Set tool per-user atau bagian system kondisional, yang memberi setiap user atau kombinasi flag cache dingin sendiri-sendiri.
• Pergantian model atau provider di tengah percakapan — cache di-scope per model, jadi request pertama setelah pergantian selalu tulis harga penuh.

Verifikasi: Baca Blok Usage, Bukan Asumsi Anda

Setiap respons Anthropic melaporkan persis apa yang terjadi, dan OpenAI serta Gemini mengekspos field setara. Biasakan mencatatnya per route:

// Response usage block — your caching dashboard
{
  "usage": {
    "cache_creation_input_tokens": 5120, // wrote to cache (1.25x price)
    "cache_read_input_tokens": 48200,    // served from cache (0.1x price)
    "input_tokens": 310,                 // uncached remainder (full price)
    "output_tokens": 850
  }
}
// total prompt = creation + read + input_tokens.
// read == 0 on repeated identical requests? You have a silent invalidator.

Saya membuat grafik tiga field ini di Grafana bersebelahan dengan jumlah request untuk setiap endpoint ber-LLM yang saya jalankan. Hari di mana sebuah deploy tidak sengaja memasukkan timestamp ke system prompt, pembacaan cache jatuh ke nol di grafik dan tagihannya menjelaskan dirinya sendiri sebelum invoice datang.

Kesimpulan

Prompt caching adalah optimasi langka yang sekaligus masif dan membosankan: tanpa trade-off kualitas, tanpa ganti model, sering tanpa perubahan arsitektur selain memindahkan string volatil keluar dari prefix. Untuk aplikasi RAG, agent dengan daftar tool besar, dan apa pun dengan system prompt gemuk, ia rutin memangkas belanja input 80 sampai 90 persen.

Mulailah dengan audit: catat token cached versus uncached selama sehari, temukan route yang membayar ulang prefix yang sama, dan perbaiki urutan perakitan prompt. Kerja satu sore dengan payoff berulang setiap bulan.