Prompt caching adalah fitur yang mengoptimalkan penggunaan API Anda dengan memungkinkan melanjutkan dari prefiks tertentu dalam prompt Anda.
cache_control
:
cache_control
. Ini memungkinkan penggunaan kembali teks besar ini di beberapa panggilan API tanpa memproses ulang setiap kali. Mengubah hanya pesan pengguna memungkinkan Anda mengajukan berbagai pertanyaan tentang buku sambil memanfaatkan konten yang di-cache, menghasilkan respons yang lebih cepat dan efisiensi yang lebih baik.
tools
, system
, dan messages
(dalam urutan tersebut) hingga dan termasuk blok yang ditandai dengan cache_control
.Model | Base Input Tokens | 5m Cache Writes | 1h Cache Writes | Cache Hits & Refreshes | Output Tokens |
---|---|---|---|---|---|
Claude Opus 4.1 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
Claude Opus 4 | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
Claude Sonnet 4 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
Claude Sonnet 3.7 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
Claude Sonnet 3.5 (deprecated) | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok |
Claude Haiku 3.5 | $0.80 / MTok | $1 / MTok | $1.6 / MTok | $0.08 / MTok | $4 / MTok |
Claude Opus 3 (deprecated) | $15 / MTok | $18.75 / MTok | $30 / MTok | $1.50 / MTok | $75 / MTok |
Claude Haiku 3 | $0.25 / MTok | $0.30 / MTok | $0.50 / MTok | $0.03 / MTok | $1.25 / MTok |
cache_control
.
Prefiks cache dibuat dalam urutan berikut: tools
, system
, kemudian messages
. Urutan ini membentuk hierarki di mana setiap level dibangun di atas level sebelumnya.
cache_control
, sistem secara otomatis memeriksa cache hit di semua batas blok konten sebelumnya (hingga sekitar 20 blok sebelum breakpoint eksplisit Anda)cache_control
. Setiap permintaan untuk meng-cache kurang dari jumlah token ini akan diproses tanpa caching. Untuk melihat apakah prompt di-cache, lihat field penggunaan respons.
Untuk permintaan bersamaan, perhatikan bahwa entri cache hanya tersedia setelah respons pertama dimulai. Jika Anda memerlukan cache hit untuk permintaan paralel, tunggu respons pertama sebelum mengirim permintaan berikutnya.
Saat ini, “ephemeral” adalah satu-satunya jenis cache yang didukung, yang secara default memiliki masa hidup 5 menit.
cache_control
tidak meningkatkan biaya Anda - Anda tetap membayar jumlah yang sama berdasarkan konten apa yang benar-benar di-cache dan dibaca. Breakpoint hanya memberi Anda kontrol atas bagian apa yang dapat di-cache secara independen.
cache_control
. Ini termasuk:
tools
system
messages.content
, untuk turn pengguna dan asistenmessages.content
, dalam turn penggunamessages.content
, dalam turn pengguna dan asistencache_control
untuk mengaktifkan caching untuk bagian permintaan tersebut.
cache_control
. Namun, blok thinking DAPAT di-cache bersama konten lain ketika muncul dalam turn asisten sebelumnya. Ketika di-cache dengan cara ini, mereka DIHITUNG sebagai token input ketika dibaca dari cache.
tools
→ system
→ messages
. Perubahan di setiap level membatalkan level tersebut dan semua level berikutnya.
Tabel berikut menunjukkan bagian cache mana yang dibatalkan oleh berbagai jenis perubahan. ✘ menunjukkan bahwa cache dibatalkan, sedangkan ✓ menunjukkan bahwa cache tetap valid.
Apa yang berubah | Cache tools | Cache system | Cache messages | Dampak |
---|---|---|---|---|
Definisi tool | ✘ | ✘ | ✘ | Memodifikasi definisi tool (nama, deskripsi, parameter) membatalkan seluruh cache |
Toggle pencarian web | ✓ | ✘ | ✘ | Mengaktifkan/menonaktifkan pencarian web memodifikasi prompt sistem |
Toggle citations | ✓ | ✘ | ✘ | Mengaktifkan/menonaktifkan citations memodifikasi prompt sistem |
Pilihan tool | ✓ | ✓ | ✘ | Perubahan pada parameter tool_choice hanya mempengaruhi blok pesan |
Gambar | ✓ | ✓ | ✘ | Menambah/menghapus gambar di mana pun dalam prompt mempengaruhi blok pesan |
Parameter thinking | ✓ | ✓ | ✘ | Perubahan pada pengaturan extended thinking (aktif/nonaktif, anggaran) mempengaruhi blok pesan |
Hasil non-tool yang diteruskan ke permintaan extended thinking | ✓ | ✓ | ✘ | Ketika hasil non-tool diteruskan dalam permintaan saat extended thinking diaktifkan, semua blok thinking yang di-cache sebelumnya dihapus dari konteks, dan pesan apa pun dalam konteks yang mengikuti blok thinking tersebut dihapus dari cache. Untuk detail lebih lanjut, lihat Caching dengan blok thinking. |
usage
di respons (atau event message_start
jika streaming):
cache_creation_input_tokens
: Jumlah token yang ditulis ke cache saat membuat entri baru.cache_read_input_tokens
: Jumlah token yang diambil dari cache untuk permintaan ini.input_tokens
: Jumlah token input yang tidak dibaca dari atau digunakan untuk membuat cache.tool_choice
dan penggunaan gambar tetap konsisten antar panggilancache_control
tambahan lebih awal dalam prompt untuk memastikan semua konten dapat di-cachetool_choice
atau keberadaan/ketidakberadaan gambar di mana pun dalam prompt akan membatalkan cache, memerlukan entri cache baru untuk dibuat. Untuk detail lebih lanjut tentang pembatalan cache, lihat Apa yang membatalkan cache.cache_control
, mereka di-cache sebagai bagian dari konten permintaan ketika Anda membuat panggilan API berikutnya dengan hasil tool. Ini biasanya terjadi selama penggunaan tool ketika Anda meneruskan blok thinking kembali untuk melanjutkan percakapan.
Penghitungan token input: Ketika blok thinking dibaca dari cache, mereka dihitung sebagai token input dalam metrik penggunaan Anda. Ini penting untuk perhitungan biaya dan penganggaran token.
Pola pembatalan cache:
cache_control
eksplisitttl
dalam definisi cache_control
seperti ini:
cache_creation_input_tokens
saat ini sama dengan jumlah nilai dalam objek cache_creation
.
A
: Jumlah token pada cache hit tertinggi (atau 0 jika tidak ada hit).B
: Jumlah token pada blok cache_control
1 jam tertinggi setelah A
(atau sama dengan A
jika tidak ada).C
: Jumlah token pada blok cache_control
terakhir.B
dan/atau C
lebih besar dari A
, mereka tentu akan menjadi cache miss, karena A
adalah cache hit tertinggi.A
.(B - A)
.(C - B)
.Contoh caching konteks besar
input_tokens
: Jumlah token dalam pesan pengguna sajacache_creation_input_tokens
: Jumlah token dalam seluruh pesan sistem, termasuk dokumen hukumcache_read_input_tokens
: 0 (tidak ada cache hit pada permintaan pertama)input_tokens
: Jumlah token dalam pesan pengguna sajacache_creation_input_tokens
: 0 (tidak ada pembuatan cache baru)cache_read_input_tokens
: Jumlah token dalam seluruh pesan sistem yang di-cacheCaching definisi tool
cache_control
ditempatkan pada tool terakhir (get_time
) untuk menandai semua tool sebagai bagian dari prefiks statis.Ini berarti bahwa semua definisi tool, termasuk get_weather
dan tool lain yang didefinisikan sebelum get_time
, akan di-cache sebagai prefiks tunggal.Pendekatan ini berguna ketika Anda memiliki set tool yang konsisten yang ingin Anda gunakan kembali di beberapa permintaan tanpa memproses ulang setiap kali.Untuk permintaan pertama:input_tokens
: Jumlah token dalam pesan penggunacache_creation_input_tokens
: Jumlah token dalam semua definisi tool dan prompt sistemcache_read_input_tokens
: 0 (tidak ada cache hit pada permintaan pertama)input_tokens
: Jumlah token dalam pesan penggunacache_creation_input_tokens
: 0 (tidak ada pembuatan cache baru)cache_read_input_tokens
: Jumlah token dalam semua definisi tool dan prompt sistem yang di-cacheMelanjutkan percakapan multi-turn
cache_control
sehingga percakapan dapat di-cache secara bertahap. Sistem akan secara otomatis mencari dan menggunakan prefiks yang di-cache sebelumnya terpanjang untuk pesan lanjutan. Artinya, blok yang sebelumnya ditandai dengan blok cache_control
kemudian tidak ditandai dengan ini, tetapi mereka masih akan dianggap sebagai cache hit (dan juga penyegaran cache!) jika mereka di-hit dalam 5 menit.Selain itu, perhatikan bahwa parameter cache_control
ditempatkan pada pesan sistem. Ini untuk memastikan bahwa jika ini dikeluarkan dari cache (setelah tidak digunakan selama lebih dari 5 menit), itu akan ditambahkan kembali ke cache pada permintaan berikutnya.Pendekatan ini berguna untuk mempertahankan konteks dalam percakapan yang sedang berlangsung tanpa berulang kali memproses informasi yang sama.Ketika ini diatur dengan benar, Anda harus melihat hal berikut dalam respons penggunaan setiap permintaan:input_tokens
: Jumlah token dalam pesan pengguna baru (akan minimal)cache_creation_input_tokens
: Jumlah token dalam turn asisten dan pengguna barucache_read_input_tokens
: Jumlah token dalam percakapan hingga turn sebelumnyaMenggabungkan semuanya: Beberapa breakpoint cache
cache_control
pada definisi tool terakhir meng-cache sem ua definisi tool.
cache_control
untuk mengaktifkan caching bertahap percakapan saat berlangsung.
input_tokens
: Token dalam pesan pengguna terakhircache_creation_input_tokens
: Token dalam semua segmen yang di-cache (tools + instruksi + dokumen RAG + riwayat percakapan)cache_read_input_tokens
: 0 (tidak ada cache hit)input_tokens
: Token dalam pesan pengguna baru sajacache_creation_input_tokens
: Token baru apa pun yang ditambahkan ke riwayat percakapancache_read_input_tokens
: Semua token yang di-cache sebelumnya (tools + instruksi + dokumen RAG + percakapan sebelumnya)Apakah saya perlu beberapa breakpoint cache atau satu di akhir sudah cukup?
Apakah breakpoint cache menambah biaya ekstra?
Berapa lama masa hidup cache?
Berapa banyak breakpoint cache yang dapat saya gunakan?
cache_control
) dalam prompt Anda.Apakah prompt caching tersedia untuk semua model?
Bagaimana prompt caching bekerja dengan extended thinking?
Bagaimana cara mengaktifkan prompt caching?
cache_control
dalam permintaan API Anda.Bisakah saya menggunakan prompt caching dengan fitur API lainnya?
Bagaimana prompt caching mempengaruhi harga?
Bisakah saya menghapus cache secara manual?
Bagaimana saya dapat melacak efektivitas strategi caching saya?
cache_creation_input_tokens
dan cache_read_input_tokens
dalam respons API.Apa yang dapat merusak cache?
Bagaimana prompt caching menangani privasi dan pemisahan data?
cache_control
di mana pun dalam prompt Anda. Untuk efisiensi biaya, lebih baik mengecualikan bagian yang sangat bervariasi (misalnya, input arbitrer pengguna) dari caching.
Bisakah saya menggunakan prompt caching dengan Batches API?
Mengapa saya melihat error `AttributeError: 'Beta' object has no attribute 'prompt_caching'` di Python?
Mengapa saya melihat 'TypeError: Cannot read properties of undefined (reading 'messages')'?