Panduan Biaya Prompt Caching: Cache Hits, Prefixes, dan Pengeluaran API Aktual

Biaya prompt caching bergantung pada tiga variabel: seberapa besar prompt Anda merupakan prefix yang dapat digunakan kembali, seberapa sering prefix tersebut berulang dalam jendela aktif cache, dan bagaimana penyedia layanan menetapkan harga penulisan cache (cache writes) dibandingkan dengan cache hits. Dapatkan ketiga angka tersebut dengan tepat dan caching dapat secara signifikan menurunkan tagihan token input Anda pada beban kerja yang repetitif; jika salah, Anda justru bisa membayar premi penulisan untuk cache yang tidak pernah digunakan kembali.

Panduan ini memisahkan apa yang didokumentasikan oleh penyedia layanan, apa yang dapat Anda verifikasi pada permukaan API publik, dan apa yang harus Anda uji sebelum berkomitmen pada strategi caching untuk kebutuhan produksi.

Poin Penting

• Biaya prompt caching memiliki dua komponen: biaya penulisan (biasanya dikenakan saat entri cache baru dibuat) dan biaya hit (biasanya dikenakan saat permintaan menggunakan kembali entri tersebut). Dokumentasi Anthropic menjelaskan perbedaan antara penulisan dan hit ini secara eksplisit; Anda harus mengonfirmasi pengganda saat ini di halaman dokumentasi sebelum memodelkan pengeluaran.
• Cache hits memerlukan kecocokan prefix yang tepat atau hampir tepat hingga breakpoint yang ditentukan. Menyusun ulang instruksi sistem, definisi tool, atau contoh few-shot sebelum breakpoint tersebut akan membatalkan cache dan memaksa penulisan ulang.
• Entri cache kedaluwarsa setelah time-to-live yang ditentukan oleh penyedia. Jika volume permintaan Anda untuk prefix tertentu terlalu jarang untuk masuk dalam jendela tersebut, Anda akan membayar biaya penulisan berulang kali alih-alih mengumpulkan penghematan dari hit.
• Dokumentasi OpenRouter mencatat bahwa perilaku dan harga prompt caching bervariasi tergantung pada penyedia dan model yang mendasarinya, sehingga strategi caching yang menghemat uang pada satu backend tidak secara otomatis berlaku untuk backend lainnya. Periksa dukungan per-model sebelum Anda merutekan trafik berdasarkan asumsi penghematan.

Untuk Apa Sebenarnya Anda Membayar dalam Prompt Caching

Prompt caching memungkinkan penyedia API menyimpan representasi yang telah diproses dari prefix prompt sehingga permintaan berikutnya yang berbagi prefix tersebut melewati komputasi yang redundan. Model penagihan yang dihasilkan dari hal ini bukanlah "token yang di-cache itu gratis." Lebih tepatnya, "token yang di-cache lebih murah saat digunakan kembali, tetapi penulisan pertama memakan biaya lebih besar daripada token input standar."

Dokumentasi prompt caching Anthropic menjabarkan struktur ini secara langsung: permintaan yang membuat entri cache baru ditagih secara berbeda dari permintaan yang melakukan hit pada entri yang sudah ada. Pengganda yang tepat berubah seiring waktu dan tergantung model, jadi anggaplah angka apa pun yang Anda lihat di postingan blog, termasuk yang ini, sebagai sesuatu yang harus diverifikasi terhadap dokumentasi saat ini, bukan sebagai konstanta tetap.

Implikasi praktisnya adalah prompt caching merupakan taruhan pada penggunaan kembali. Jika prompt sistem, skema tool, atau blok konteks yang diambil dikirim sekali dan tidak pernah diulang, caching menambahkan premi penulisan tanpa penghematan hit yang mengimbangi. Jika blok yang sama dikirim ratusan kali dalam jendela aktif cache, penghematan hit dapat melebihi biaya penulisan dengan selisih yang besar.

Cara Kerja Cache Hits: Prefixes, Prefixes, dan Breakpoints

Cache hits berbasis prefix, bukan berbasis konten dalam pengertian samar. Bagian yang di-cache dari sebuah prompt harus cocok dengan permintaan masuk token-demi-token hingga titik di mana batas cache, yang terkadang disebut breakpoint, ditetapkan. Dokumentasi Anthropic menjelaskan ini sebagai mekanisme eksplisit di mana pengembang menandai bagian mana dari prompt yang memenuhi syarat untuk caching, biasanya instruksi sistem yang stabil, definisi tool, dan dokumen referensi panjang yang tidak berubah antar panggilan.

Hal ini memiliki konsekuensi teknis langsung: apa pun yang Anda tempatkan sebelum breakpoint cache harus identik secara byte di seluruh permintaan, termasuk spasi dan urutan. Kesalahan umum adalah menyisipkan variabel per-permintaan (seperti stempel waktu atau ID pengguna) ke dalam prompt sistem sebelum batas cache. Variabel tunggal tersebut akan menggagalkan cache untuk seluruh prefix, dan Anda membayar biaya penulisan pada setiap panggilan alih-alih mendapatkan hit.

Perbaikannya mudah: simpan konten yang benar-benar statis (definisi tool, instruksi gaya bahasa, dokumen referensi besar) dalam prefix yang di-cache, dan pindahkan apa pun yang spesifik untuk permintaan ke dalam suffix yang tidak di-cache, biasanya pesan pengguna.

Masa pakai cache sama pentingnya dengan desain prefix. Dokumentasi Anthropic menjelaskan durasi cache default yang diukur dalam hitungan menit, dengan opsi durasi yang lebih lama tersedia untuk beban kerja yang membutuhkannya. Jika pola trafik Anda mengirim prefix bersama sekali setiap beberapa menit, cache yang berumur pendek dapat kedaluwarsa sebelum permintaan berikutnya tiba, dan Anda akhirnya membayar biaya penulisan berulang kali. Beban kerja frekuensi tinggi (sesi chat, loop agen, pipeline batch yang berjalan berturut-turut) jauh lebih baik daripada panggilan yang jarang dan sporadis.

Memodelkan Pengeluaran API Nyata: Pendekatan Kerja

Daripada menyatakan persentase penghematan, modelkan beban kerja Anda sendiri dengan bentuk berikut. Contoh ini mengilustrasikan struktur permintaan secara konseptual; periksa nama field yang tepat dan harga saat ini pada dokumentasi penyedia sebelum Anda mengimplementasikannya.

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

Penanda cache_control pada blok sistem memberi sinyal bahwa konten ini adalah kandidat caching. Panggilan pertama dalam sesi membayar biaya penulisan untuk blok tersebut. Setiap panggilan berikutnya dalam jendela aktif cache yang menggunakan kembali prefix yang identik membayar tarif hit alih-alih tarif input penuh untuk token tersebut.

Untuk memperkirakan apakah ini layak diimplementasikan untuk layanan Anda, kumpulkan empat angka dari log Anda sendiri:

1. Ukuran prefix: jumlah token dari konten stabil yang ingin Anda cache (prompt sistem, skema tool, dokumen referensi).
2. Frekuensi panggilan dalam jendela TTL: berapa banyak permintaan yang menggunakan kembali prefix yang tepat tersebut di dalam durasi aktif cache.
3. Tarif penulisan dan hit: diambil dari dokumentasi penyedia saat ini, bukan diasumsikan dari ingatan.
4. Variabilitas suffix: apakah bagian yang tidak di-cache dari prompt Anda kecil dibandingkan dengan bagian yang di-cache, karena penghematan berskala dengan seberapa banyak total prompt yang berada di belakang breakpoint cache.

Jika prefix Anda besar, frekuensi panggilan Anda di dalam jendela TTL tinggi, dan suffix Anda kecil, caching kemungkinan besar akan mengurangi pengeluaran. Jika salah satu dari ketiga kondisi tersebut lemah, lakukan perbandingan biaya berdampingan sebelum meluncurkan caching secara luas. Panduan TokenLab tentang cara memangkas biaya API AI membahas serangkaian tuas yang lebih luas di luar caching, termasuk pemilihan model dan batching, di /blog/cut-ai-api-costs-30-percent.

Tabel Keputusan: Kapan Prompt Caching Menguntungkan

Pola beban kerja	Cache kemungkinan membantu	Catatan
Prompt sistem panjang atau skema tool digunakan kembali di banyak panggilan dalam satu sesi	Ya	Kasus klasik; biaya penulisan diamortisasi di seluruh hit
Dokumen besar yang diambil digunakan kembali dalam serangkaian pertanyaan tindak lanjut yang singkat	Ya, jika panggilan masuk dalam TTL	Konfirmasi TTL terhadap dokumentasi saat ini sebelum mengasumsikan jendela penggunaan kembali
Prompt sekali pakai tanpa trafik berulang	Tidak	Premi penulisan tanpa hit untuk mengimbanginya
Prompt dengan variabilitas tinggi di mana bagian "stabil" terus berubah	Tidak	Setiap perubahan sebelum breakpoint membatalkan cache
Loop agen dengan definisi tool yang berulang di banyak giliran	Ya	Skema tool adalah kandidat utama caching
Pekerjaan batch frekuensi rendah yang berjarak melebihi TTL cache	Tidak	Cache kedaluwarsa sebelum digunakan kembali; bayar biaya penulisan setiap saat
Perutean multi-penyedia di mana hanya beberapa backend yang mendukung caching	Verifikasi per model	Jangan berasumsi dukungan caching berpindah antar penyedia

Gunakan tabel ini sebagai daftar periksa awal, bukan jawaban akhir. Konfirmasi TTL, harga penulisan/hit, dan mekanika breakpoint terhadap dokumentasi penyedia untuk model spesifik yang ingin Anda gunakan, karena detail ini berubah dan bervariasi menurut keluarga model.

Perbedaan Penyedia yang Harus Anda Verifikasi Sebelum Berkomitmen

Prompt caching tidak diimplementasikan secara identik di mana-mana, dan itu penting jika Anda merutekan trafik ke berbagai penyedia atau model. Dokumentasi OpenRouter tentang praktik terbaik prompt caching mencatat bahwa dukungan dan perilaku caching berbeda menurut penyedia yang mendasarinya, yang berarti strategi yang disetel untuk mekanika cache satu model tidak secara otomatis berlaku saat Anda beralih model atau merutekan melalui backend yang berbeda.

Jika arsitektur Anda menggunakan perutean model untuk mengontrol biaya (misalnya, mengirim tugas klasifikasi rutin ke model berbiaya lebih rendah seperti DeepSeek V4 Flash, GLM-5.2, atau Gemini 3.5 Flash sementara mencadangkan Claude Sonnet 5 atau GPT-5.5 untuk tugas penalaran yang lebih sulit), Anda perlu memeriksa dukungan caching secara independen untuk setiap model dalam tabel perutean tersebut. Strategi caching yang divalidasi terhadap dokumentasi satu model bukanlah asumsi yang aman untuk model lain. Halaman peringkat TokenLab melacak perbedaan tingkat model yang dapat Anda gunakan sebagai titik referensi awal di /models/rankings, dan analisis benchmark perutean di /blog/ai-model-routing-benchmark-cost-per-task membahas bagaimana keputusan perutean berinteraksi dengan biaya per-tugas, yang digabungkan dengan keputusan caching alih-alih menggantikannya.

Keterbatasan Analisis Ini

Panduan ini menjelaskan mekanika umum prompt caching sebagaimana didokumentasikan oleh Anthropic dan dirujuk oleh OpenRouter pada tanggal yang diamati di atas. Panduan ini tidak menyertakan pengganda penulisan/hit yang tepat, durasi TTL yang tepat, atau harga per-model, karena angka-angka tersebut berubah dan berbeda menurut model. Sebelum Anda membangun model biaya untuk trafik produksi, ambil angka saat ini langsung dari dokumentasi penyedia yang ditautkan di atas daripada mengandalkan angka tetap yang dikutip dalam konten pihak ketiga, termasuk artikel ini. Perilaku caching untuk model yang berorientasi pada penalaran, prompt multimodal, dan jendela konteks yang sangat panjang mungkin juga berbeda dari pola prefix-caching umum yang dijelaskan di sini; verifikasi terhadap dokumentasi untuk model spesifik yang ingin Anda gunakan.

FAQ

Apakah prompt caching selalu mengurangi pengeluaran API? Tidak. Ini mengurangi pengeluaran hanya ketika prefix yang stabil digunakan kembali cukup sering dalam jendela aktif cache untuk mengimbangi biaya penulisan. Prompt yang sporadis atau sangat bervariasi sering kali memakan biaya lebih besar dengan caching diaktifkan daripada tanpa caching.

Apa yang merusak cache hit? Setiap perubahan pada konten prompt sebelum breakpoint cache, termasuk spasi, urutan token, atau variabel tunggal yang disisipkan ke dalam prompt sistem yang seharusnya statis. Kecocokan harus tepat hingga breakpoint.

Apakah prompt caching diimplementasikan dengan cara yang sama di semua penyedia? Tidak. Anthropic mendokumentasikan mekanisme kontrol cache eksplisit dengan harga penulisan dan hit yang ditentukan. Dokumentasi OpenRouter mencatat bahwa dukungan dan harga caching bervariasi menurut penyedia dan model yang mendasarinya, jadi Anda harus memverifikasi dukungan per model alih-alih berasumsi bahwa dukungan tersebut dapat berpindah.

Jika Anda sedang mengevaluasi apakah prompt caching, perutean model, atau kombinasi keduanya sesuai dengan pola trafik Anda, mulailah dengan TokenLab untuk membandingkan opsi model dan struktur biaya sebelum Anda berkomitmen pada pengeluaran produksi.