Prompt cache tidak mengingat promptmu. Dia mengingat prefix yang pernah ditulis permintaan sebelumnya, di batas yang ditandai permintaan itu, lalu mengembalikan yang terpanjang yang masih cocok. Semua kejutan soal token caching mengalir dari kalimat itu, termasuk tagihan yang tidak kamu duga.
Ini versi terkecil dari kejutannya. System prompt-mu 512 token. Giliran pertama mengirim 512 token itu. Giliran kedua mengirim 512 yang sama ditambah pesan 512 token. Provider membaca 512 token dari cache, menagih harga penuh untuk 512 sisanya, dan paruh kedua itu tetap di luar cache sampai ada permintaan berikutnya yang menulisnya. Giliran ketiga mengirim 1.536 token dan membaca 1.024.
Cache tumbuh satu giliran di belakangmu. Itu bukan bug di provider mana pun; memang begitu cara kerja prefix cache.
Poin Penting
- Entri cache adalah hash sebuah prefix, ditulis di batas yang kamu tandai. Entri itu tidak pernah tumbuh sendiri: permintaan yang lebih panjang hanya memakai ulang bagian yang sudah ditulis permintaan sebelumnya.
- Kasus 512 ke 1.024 cuma punya satu jawaban. 512 token pertama kembali dengan harga baca, 512 token baru dibayar penuh, dan baru bisa dipakai ulang mulai permintaan berikutnya.
- Panjang minimum menentukan apakah kamu dapat hit sama sekali. 512 token bisa di-cache di model Anthropic terbaru, 1.024 di GPT-5.6 ke atas, dan 2.048 sampai 6.144 di Gemini tergantung modelnya.
- Posisi breakpoint adalah seluruh permainannya. Di blok yang berubah setiap permintaan, tiap penulisan terbuang; di ujung blok stabil, satu penulisan bertahan sepanjang percakapan.
- Ukur penghitung yang dilaporkan, bukan saklar fiturnya. Setiap provider memberitahu berapa token yang datang dari cache pada permintaan itu, dan angka itulah satu-satunya bukti caching bekerja.
Empat buku aturan, satu mekanisme
Semua provider besar meng-cache tiga hal yang sama: key-value state model untuk satu urutan token, hash prefix yang menghasilkannya, dan masa kedaluwarsa. Mereka berbeda di empat tempat, dan tiap perbedaan muncul di tagihan.
Caching implisit menyala secara bawaan dan provider yang memilih di mana prefix yang bisa dipakai ulang berakhir. OpenAI melakukannya di semua model yang didukung, Gemini menyebutnya implicit caching, dan DeepSeek menjalankannya di disk tanpa perlu opt-in sama sekali.
Breakpoint eksplisit menaruh kendali batas di tanganmu. Anthropic menerima cache_control di sebuah blok, maksimal empat per permintaan. OpenAI punya gagasan yang sama di GPT-5.6 ke atas lewat prompt_cache_options.mode: "explicit", juga dengan empat penulisan per permintaan.
Objek cache bernama adalah mode eksplisit Gemini: kamu membuat cache, merujuknya dengan nama, dan membayar penyimpanan per token-jam di atas harga token input. TTL-nya dari satu menit sampai tanpa batas, bawaan 60 menit.
Sticky routing bukan cache. OpenRouter melacak sebuah percakapan supaya permintaan berikutnya mendarat di provider yang masih menyimpan prefix-mu, dan kunci percakapannya diturunkan dari hash pesan system pertama dan pesan user pertama. System prompt yang berubah tiap menit merusak kunci itu juga, lalu percakapannya pindah ke tempat yang cache-nya kosong.
Timestamp di definisi tool membatalkan ketiga tingkat. Timestamp yang sama di pesan terakhir hanya membatalkan yang sesudahnya.
Angka di bawah datang dari dokumentasi provider masing-masing pada November 2026. Pengalinya mirip antar vendor; minimum dan masa hidupnya tidak, dan dua hal itulah yang menentukan apakah sebuah permintaan kena cache.
| Anthropic | OpenAI (GPT-5.6+) | Gemini | DeepSeek | |
|---|---|---|---|---|
| Pemicu tulis | blok cache_control, atau otomatis di blok terakhir yang bisa di-cache |
breakpoint eksplisit, atau implisit di pesan terakhir yang memenuhi syarat | implisit secara bawaan, atau cache bernama | otomatis di batas permintaan |
| Prefix minimum | 512 token di model terbaru, 1.024 sampai 4.096 di model lama | 1.024 token input yang terlihat | 2.048 di Gemini 2, 4.096 di Gemini 3 dan 4, 6.144 di sebagian preview 3.x | tidak didokumentasikan |
| Pencarian | hash prefix di tiap breakpoint, mundur 20 blok | hash breakpoint, ditambah sampai 20 ujung pesan sebelumnya | best effort | harus cocok penuh dengan unit prefix tersimpan |
| Masa hidup bawaan | 5 menit, diperpanjang saat dipakai; 1 jam kalau diminta | 30 menit, atau 12 jam dengan harga tulis lebih tinggi | sampai 24 jam untuk implisit; 60 menit bawaan untuk eksplisit | jam sampai hari, best effort |
| Harga baca | 0,1x input, 0,05x di Sonnet 5.5 dan Opus 5.5 | 0,1x input, 0,05x di GPT-6.1 Sol dan Terra | diskon 90% | harga hit yang lebih murah |
| Harga tulis | 1,25x untuk 5 menit, 2x untuk 1 jam | 1,25x untuk 30 menit, 2,5x untuk 12 jam | harga input biasa, ditambah penyimpanan kalau eksplisit | bukan harga terpisah |
Token yang kena cache tetap dihitung ke batas token-per-menit di OpenAI, jadi semua ini tidak menambah throughput. Yang dibeli cuma uang.
Pertanyaan 512 token
Ambil prefix 512 token, pesan 512 token per giliran, dan pengali yang dipakai sebagian besar model: input $2 per juta token, tulis 1,25x, baca 0,1x.
Giliran pertama menulis 512 token seharga $0,00128 dan tidak membaca apa pun. Giliran kedua membaca 512 seharga $0,00010 dan menulis 512 baru seharga $0,00128. Giliran ketiga membaca 1.024 dan menulis 512 baru. Selama tiga giliran itu totalnya $0,0041, dibanding $0,0061 tanpa caching sama sekali.
Ada dua hal yang rusak di sini, dan keduanya cukup umum sampai dokumentasinya menyebutnya.
Memperpanjang pesan alih-alih menambah pesan baru. Panduan OpenAI tegas soal ini. Kalau permintaan pertama berakhir dengan pesan user berisi Content A, lalu permintaan kedua memperpanjang pesan yang sama menjadi Content A + Content B, batas lama sekarang berada di dalam sebuah pesan. Prefix yang tersimpan tidak dipakai ulang di situ tanpa breakpoint eksplisit. DeepSeek menyatakan aturan yang sama dengan kata lain. Permintaan A + B lalu A + B + C kena unit A + B; permintaan A + B lalu A + C tidak kena apa pun, walau ia mengajari sistem menyimpan A yang dipakai bersama untuk permintaan ketiga.
Jatuh di bawah minimum. Di GPT-5.6 ke atas, 512 token tidak bisa di-cache sama sekali, karena minimumnya 1.024 token input yang terlihat; hit pertama yang mungkin adalah giliran kedua, dan itu mencakup seluruh 1.024. Di Gemini 2 tunggunya 2.048 token, dan di Gemini 3 dan 4 tunggunya 4.096. Model Anthropic terbaru menerima 512, dan itulah sebabnya contoh di atas mungkin di sana dan belum tentu di tempat lain.
Dua breakpoint yang membohongimu
Breakpoint di blok yang berubah setiap permintaan menulis entri baru tiap kali dan tidak pernah membaca satu pun. Dokumentasi Anthropic menyebut ini kesalahan umum dengan kata yang persis. Pencariannya menelusuri mundur mencari entri yang ditulis permintaan sebelumnya, bukan mencari konten yang stabil. Kalau tidak ada yang menulis entri di ujung blok statismu, tidak ada apa pun untuk ditemukan di balik sebuah timestamp.
Jebakan kedua adalah jarak. Anthropic menelusuri mundur 20 posisi blok dari sebuah breakpoint; OpenAI memeriksa sampai 20 ujung pesan sebelumnya di mode implisit. Satu giliran yang menambahkan lebih dari 20 blok, atau percakapan yang tumbuh melewatinya, meninggalkan entri terakhir di luar jendela. Untuk itulah breakpoint kedua dan ketiga ada.
Tujuh setelan yang menentukan hit rate
- Urutkan berdasarkan seberapa sering bagiannya berubah. Definisi tool, lalu instruksi, lalu materi referensi, lalu percakapan. Apa pun yang berubah per permintaan tempatnya setelah semua yang tidak berubah.
- Taruh breakpoint di ujung blok stabil terakhir. Bukan di blok terakhir. Di percakapan yang tumbuh, blok terakhir berhasil, karena giliran sebelumnya menulis di sana; di prompt dengan akhiran yang berubah, tidak.
- Tambahkan, jangan tulis ulang. Ringkasan adalah pesan baru di ujung, bukan versi lebih kecil dari transkrip di awal. Compaction dan pemotongan mereset prefix sejak token pertama yang berubah.
- Jaga array tool tetap identik byte demi byte. Matikan tool dengan
tool_choice: "none"alih-alih menghapus definisinya, dan jangan pernah menaruh id sesi atau timestamp snapshot di deskripsi. - Cocokkan masa hidup dengan jedanya. Buku panduan yang dipakai sepanjang hari butuh penulisan satu jam dengan 2x. Ekor percakapan butuh yang bawaan, karena toh kedaluwarsa di antara sesi.
- Kirim permintaan yang berhubungan ke cache yang sama. Di model OpenAI sebelum GPT-5.6 itu berarti
prompt_cache_keyyang stabil, dibidik sekitar 15 permintaan per menit per kunci. Lewat router, artinya prefix yang tidak berubah, supaya kunci routing-nya tidak ikut berubah. - Baca penghitungnya.
cache_read_input_tokens,cached_tokens,prompt_cache_hit_tokens,cachedContentTokenCount. Tiap provider melaporkan token yang datang dari cache pada permintaan itu. Hit rate mendekati nol pada prompt yang kelihatan statis berarti prefix-nya berubah di tempat yang belum kamu periksa.
Yang tidak dibeli caching
Token input yang kena cache tetap dihitung ke batas rate limit di OpenAI, jadi caching tidak akan menyelamatkan loop yang sedang di-throttle. Entri cache di Anthropic baru tersedia setelah respons pertama mulai, jadi permintaan paralel yang datang bersamaan tidak bisa saling menolong. Konten system yang disembunyikan tidak dihitung ke prefix minimum di kedua provider. Cache terisolasi per organisasi dan, di Claude API, per workspace, jadi dua salinan prompt yang sama di dua workspace adalah dua penulisan. Dan Gemini menagih penyimpanan untuk cache eksplisit per token-jam, meteran kedua yang bisa membengkak kalau cache-nya dibiarkan 24 jam.
giliran dalam loop
Tidak ada satu pun dari ini yang mengubah bentuk kurva biayanya. Caching membagi tagihannya sekitar lima kali dan membiarkan pertumbuhannya, karena transkripnya tetap tumbuh dan tetap kamu kirim ulang tiap giliran. Di loop empat puluh giliran yang dihitung di artikel sebelumnya, caching memindahkan $2,16 ke $0,43 dan kedua angka tetap naik mengikuti kuadrat jumlah giliran.
Urutkan prompt berdasarkan seberapa sering bagiannya berubah, taruh breakpoint di ujung bagian yang tidak berubah, dan ukur penghitungnya di permintaan berikutnya. Kalau hit rate-nya mendekati nol padahal prompt-nya kelihatan statis, prefix-nya berubah di array tool, di baris pertama system prompt, atau di suatu tempat di atas blok yang ingin kamu cache.