Catatan penulis: Rasio hit cache petunjuk Claude tiba-tiba turun ke 0, atau tagihan tidak kunjung turun? Anda bisa memakai tiga langkah diagnostics untuk menemukan lokasi percabangan awalan (prefix), lalu mengombinasikannya dengan usage untuk menentukan apakah cache benar-benar hit. Artikel ini juga menjelaskan cara memeriksa sendiri saat memakai layanan proksi APIYI. (Kalau Anda mengalami masalah ini, setelah membaca artikel ini kirimkan saja artikelnya ke Agent Anda untuk ditelusuri.)
Cache tidak hit bukanlah hal mistis, API akan memberi tahu Anda dari segmen mana awalan mulai bercabang. Anda hanya perlu mengirimkan kembali id respons dari putaran sebelumnya, dan Anda akan melihat titik pertama yang tidak cocok ada di model, system, tools, atau messages.
Ini bukan artikel ulasan rilis fitur. Artikel ini ditujukan untuk developer yang sudah menggunakan cache petunjuk Claude, tetapi rasio hit-nya tiba-tiba menjadi nol atau tagihannya tetap tinggi. Semua langkah pemeriksaan akan dijelaskan dengan jelas, termasuk apa yang akan Anda lihat di setiap langkah.
Nilai utama: Setelah membaca artikel ini, Anda dapat menemukan penyebab cache tidak berlaku dalam tiga kali permintaan. Anda juga dapat membedakan apa yang dijelaskan oleh diagnostics dan usage masing-masing, serta mengetahui dua field mana yang perlu dibandingkan saat memakai layanan proksi.
Poin inti diagnostik cache Claude diagnostics
Satu kalimat untuk menjelaskan apa itu: kirimkan id respons putaran sebelumnya, lalu API akan membandingkan dua permintaan dan menunjukkan di mana titik percabangan pertama terjadi — di model, system, tools, atau messages. Dulu, ketika cache gagal secara diam-diam, Anda hanya bisa melihat usage.cache_read_input_tokens menjadi 0, tanpa tahu bagian mana yang berubah.
| Poin | Penjelasan | Nilai untuk Anda |
|---|---|---|
| Tombol aktif | Fingerprint hanya disimpan jika body permintaan di level atas menyertakan objek diagnostics |
Tidak perlu mengubah logika bisnis, cukup tambah satu field |
| Cara membandingkan | Kirim id respons putaran sebelumnya lewat previous_message_id |
Langsung menemukan segmen percabangan pertama |
| Field kesimpulan | cache_miss_reason memberikan salah satu dari enam tipe |
Setiap tipe punya lokasi perbaikan yang jelas |
| Dikombinasikan dengan metrik | Perlu dilihat bersama usage.cache_read_input_tokens |
Menghindari salah mengira “tidak ada perbedaan” sebagai “tidak berfungsi” |
| Cakupan ketersediaan | Hanya tersedia di Claude API resmi | Jika lewat jalur lain, perlu memakai pemeriksaan mandiri lewat usage |
Linimasa diagnostik cache Claude
Fitur ini dirilis dalam bentuk beta pada Mei 2026, saat itu perlu menyertakan header anthropic-beta: cache-diagnosis-2026-04-07. Pada September, aturannya sempat diperketat: hanya permintaan yang secara eksplisit menyertakan objek diagnostics yang fingerprint-nya disimpan, sedangkan permintaan yang hanya membawa header tidak akan dicatat.
Pada 23 September fitur ini menjadi versi resmi, tidak lagi memerlukan cache-diagnosis-2026-04-07, dan permintaan yang membawa header lama tetap bisa digunakan seperti biasa. Sekarang respons POST /v1/messages selalu menyertakan field diagnostics, dengan nilai null jika tidak diaktifkan. Jadi melihat field ini bernilai null bukan berarti ada masalah pada API.
Fingerprint hanya menyimpan hash dan perkiraan jumlah token, bukan konten petunjuk asli. Fingerprint diindeks berdasarkan response id, cakupannya terbatas pada organisasi dan workspace ini, serta masa simpannya relatif singkat.
3 langkah memakai diagnostics untuk mendiagnosis tingkat cache hit Claude
Tiga langkah berikut disusun berdasarkan penjelasan field resmi. Jika Anda memanggil lewat APIYI, untuk API native Messages isi base_url dengan https://api.apiyi.com/v1, dan path request-nya /v1/messages. Namun perlu diingat, bagian pengujian di bawah akan menjelaskan kondisi pengembalian diagnostics yang sebenarnya dalam skenario layanan proksi API.
Langkah 1: Tambahkan objek diagnostics di level teratas request
diagnostics adalah satu-satunya sakelar. Request yang tidak membawanya tidak akan menyimpan fingerprint, sehingga nanti tidak ada yang bisa dibandingkan. Pada putaran pertama belum ada objek pembanding, jadi isi previous_message_id dengan null, artinya “mulai mencatat dari putaran ini”.
- Header request tetap memakai versi biasa:
anthropic-version: 2023-06-01 - Setelah versi resmi, header ini tidak perlu dibawa lagi:
anthropic-beta: cache-diagnosis-2026-04-07 - Tambahkan di level teratas body request:
"diagnostics": {"previous_message_id": null} - Blok
systemyang perlu di-cache tetap diberi breakpoint seperti biasa:"cache_control": {"type": "ephemeral"} - Yang akan terlihat:
diagnosticspada respons bernilainull,cache_read_input_tokensbiasanya 0, dancache_creation_input_tokenslebih besar dari 0
Melihat null di putaran pertama bukan berarti gagal. Putaran ini sedang menulis cache, dan memang tidak ada putaran sebelumnya untuk dibandingkan, jadi tidak perlu troubleshooting.
Langkah 2: Setiap putaran berikutnya, kirim id respons putaran sebelumnya
Mulai putaran kedua, isi previous_message_id dengan id respons putaran sebelumnya. Kesalahan paling umum adalah hanya membawa diagnostics di putaran pertama lalu melewatkannya setelah itu. Request yang ditunjuk pada putaran berikutnya tidak tercatat, sehingga hasilnya mengembalikan previous_message_not_found.
- Body request putaran kedua:
"diagnostics": {"previous_message_id": "<id respons putaran pertama>"} - Body request putaran ketiga:
"diagnostics": {"previous_message_id": "<id respons putaran kedua>"} - Pola perulangan multi-putaran: putaran pertama
null, putaran keduar1.id, putaran ketigar2.id, dan seterusnya - Saat memakai streaming, hasilnya muncul di event
message_start, dan id juga diteruskan dari putaran ke putaran - Yang akan terlihat: jika jarak antarputaran cukup pendek dan masih dalam workspace yang sama, hasil perbandingan mulai muncul di respons
Langkah 3: Baca cache_miss_reason dan perbaiki sesuai jenisnya
diagnostics punya tiga nilai; pahami dulu sebelum membacanya:
null: request tidak membawadiagnostics; atauprevious_message_idbernilainull; atau perbandingan sudah selesai dan tidak ditemukan perbedaan{"cache_miss_reason": null}: perbandingan masih berjalan; karena respons dimulai terlalu cepat, putaran ini belum menyimpulkan apa-apa, lihat putaran berikutnyacache_miss_reasonberupa objek: sudah ada kesimpulan, berisi jenis percabangan dan detailnya- Yang akan terlihat: setelah mendapatkan jenisnya, ubah sesuai tabel di bagian berikutnya. Perbaiki percabangan paling awal lebih dulu, karena yang dilaporkan hanya titik perbedaan pertama; masalah setelahnya bisa tertutup olehnya
🚀 Mulai cepat: Jika ingin memastikan apakah prefix cache Anda bisa ditulis dan di-hit, di APIYI apiyi.com Anda dapat memakai Key yang sama untuk berganti-ganti model Claude dan melakukan perbandingan dua putaran. Fokus pada apakah dua angka cache write dan read di usage cocok.
Enam jenis cache_miss_reason dan lokasi perbaikannya
Setelah mendapatkan cache_miss_reason, cocokkan dengan tabel berikut untuk tahu bagian mana yang perlu diubah:
| Jenis | Arti | Ubah di mana |
|---|---|---|
model_changed |
Model berbeda dari putaran sebelumnya, misalnya karena routing, A/B testing, atau fallback mengganti model. Cache diisolasi per model | Tetapkan model yang sama dalam satu sesi percakapan yang di-cache |
system_changed |
system berubah, paling sering karena disisipi timestamp, request ID, atau nilai lain yang berbeda di setiap permintaan | Ubah system menjadi konstanta yang stabil byte per byte, lalu pindahkan data dinamis ke pesan user pertama setelah breakpoint |
tools_changed |
Tool ditambah, dihapus, atau urutannya ditukar, atau hasil serialisasi input_schema tidak stabil |
Kirim daftar tool yang sama di setiap putaran, urutan tetap, serialisasi diurutkan berdasarkan key |
messages_changed |
Pesan yang lebih awal diubah, diurutkan ulang, atau dihapus, bukan ditambahkan di akhir | Riwayat hanya ditambahkan, konten assistant dan hasil tool dikembalikan apa adanya |
previous_message_not_found |
Sidik jari yang cocok tidak ditemukan, bukan berarti request berubah | Sertakan diagnostics di setiap putaran, jangan lintas workspace, jeda antar putaran jangan terlalu lama |
unavailable |
Hasil diagnostik tidak didapat di putaran ini, misalnya karena tool_choice, thinking, context_management, output_config, output_format, atau kumpulan beta header tidak konsisten, bisa juga karena percakapan terlalu panjang |
Sepanjang siklus hidup satu percakapan yang di-cache, parameter-parameter ini harus tetap sama |
Keempat jenis *_changed juga menyertakan cache_missed_input_tokens, yang menunjukkan kira-kira berapa banyak token input yang seharusnya bisa di-cache tapi hilang setelah titik percabangan. Angka ini dikonversi dari panjang byte, hanya bisa dipakai untuk menilai orde besaran, bukan angka tagihan, dan kadang bisa lebih besar daripada usage.input_tokens.
Hanya melihat diagnostics bisa salah判断: gabungkan dengan usage untuk menilai cache hit Claude
diagnostics menjawab “apakah request saya berubah”, sedangkan usage.cache_read_input_tokens menjawab “apakah cache hit”. Kedua pertanyaan ini berbeda, dan jika hanya melihat salah satunya, mudah menarik kesimpulan yang salah.
| Hasil diagnostics | Token baca cache | Kesimpulan | Yang perlu dilakukan |
|---|---|---|---|
null |
Tinggi | Prefix stabil, cache hit | Tidak perlu tindakan |
null |
Rendah atau 0 | Request tidak berubah, tetapi cache sudah kedaluwarsa | Perpendek interval request, atau gunakan TTL 1 jam |
*_changed |
Rendah | Request berubah sehingga tidak hit | Perbaiki sesuai tabel perbandingan di bagian sebelumnya |
*_changed |
Tinggi | Perubahan terjadi di posisi belakang, breakpoint di depan masih hit | Layak diperbaiki, tetapi dampaknya kecil |
Perlu ditekankan sekali lagi: null bukan berarti tidak berfungsi, bisa jadi justru itu hasil terbaik. Ada beberapa kondisi yang tidak berlaku untuk tabel ini: putaran pertama, cache_miss_reason bernilai null (perbandingan masih berlangsung), serta previous_message_not_found dan unavailable. Dalam kondisi-kondisi ini, sama sekali tidak ada perbandingan yang valid.
Jika Anda belum yakin putaran mana yang termasuk kotak mana, Anda bisa mengirim request yang sama dua putaran berturut-turut di APIYI apiyi.com, catat angka baca-tulis cache setiap putaran, lalu cocokkan dengan matriks di atas untuk menyingkirkan satu per satu.
Alasan Umum Tingkat Cache Hit Rendah pada Claude: Tiga Syarat Wajib
Sering kali tingkat cache hit rendah bukan karena request-nya berubah, melainkan karena cache-nya memang tidak pernah tertulis sejak awal. Ketiga syarat berikut harus terpenuhi semua; jika satu saja tidak terpenuhi, cache tidak akan berlaku:
- Wajib secara eksplisit menambahkan
cache_control: bisa diletakkan pada blok konten tertentu sebagai breakpoint eksplisit, atau diletakkan di tingkat atas request agar sistem otomatis menempatkan breakpoint pada blok terakhir yang bisa di-cache. Jikacontentberupa string polos tanpa blok konten yang bisa diberi penanda, maka tidak akan pernah di-cache. - Panjangnya mencapai panjang minimum yang bisa di-cache: di Claude API, Sonnet 5.5 dan Opus 5.5 sama-sama 512 token. Jika prefix tidak cukup panjang, cache akan diabaikan secara diam-diam dan tidak memunculkan error.
- Prefix identik byte per byte: riwayat hanya ditambahkan di belakang,
systemdantoolstetap stabil. Spasi, urutan field JSON, atau timestamp — jika satu saja berubah, akan dianggap sebagai prefix baru.
Dokumentasi cache APIYI juga mencantumkan dua batasan wajib: maksimal 4 breakpoint cache_control per request, dan setiap breakpoint hanya melihat ke belakang maksimal 20 content block terakhir. Untuk percakapan multi-turn yang panjang, menandai hanya pada pesan terakhir tidak akan mencakup seluruh riwayat.
TTL juga sering terlewat. Default-nya 5 menit, dan setiap cache hit akan memperpanjang masa berlaku, tetapi penghitungan waktu dimulai dari request saat penulisan atau pembacaan tersebut, bukan dari saat respons selesai. Jika satu respons streaming memakan waktu 4 menit untuk output, request berikutnya harus dikirim dalam kisaran 1 menit. Jika membutuhkan jendela waktu yang lebih panjang, bisa menuliskan "ttl": "1h" di dalam cache_control.
Perhitungan biaya saat cache hit rate Claude turun ke 0
Berikut daftar harganya lebih dulu, dalam USD per juta token. Data per 2026-10-25; harga real-time di konsol tetap menjadi acuan:
| Model | Input | Output | Cache read | Write 5 menit | Write 1 jam |
|---|---|---|---|---|---|
| Claude Sonnet 5.5 | $2 | $10 | $0.10 | $2.50 | $4 |
| Claude Opus 5.5 | $4 | $20 | $0.20 | $5 | $8 |
| Claude Haiku 5.5 (di bawah 100 ribu token) | $0.1 | $0.5 | $0.01 | $0.125 | $0.20 |
| Claude Haiku 5.5 (di atas 100 ribu token) | $0.50 | $2.50 | $0.05 | $0.625 | $1 |
Rasio pengali perlu dilihat secara terpisah. Panduan cache APIYI memberikan acuan umum: cache hit 0.1×, write 5 menit 1.25×, write 1 jam 2×. Sonnet 5.5 mengikuti penyesuaian resmi pada 7 Oktober: cache read turun dari $0.20 ke $0.10, menjadi 0.05× harga input dasar, sedangkan harga write tidak berubah.
Penyesuaian ini bukan penurunan harga menyeluruh; cache read Sonnet 5 masih $0.20. Jadi jangan pakai 0.1× untuk menghitung Sonnet 5.5. Model dan harga spesifik mengacu pada daftar model di platform.
Titik balik modal dihitung dengan acuan umum 0.1× dari platform: TTL 5 menit cukup dipakai ulang dua kali untuk balik modal (1.25 + 0.1 = 1.35, lebih rendah dari 2.0 tanpa cache); TTL 1 jam perlu dipakai ulang tiga kali (2 + 0.2 = 2.2, lebih rendah dari 3.0).
Lihat satu contoh perhitungan. Sonnet 5.5, prefix tetap 30 ribu token, dikirim 200 kali sehari, semuanya dalam TTL 5 menit:
- Semua cache hit: 200 × 30 ribu × $0.10/juta = $0.60, ditambah satu kali write $0.075, total sekitar $0.675/hari
- Semua cache miss: 200 × 30 ribu × $2/juta = $12/hari
Selisih tagihan sehari penuh sekitar 17.8 kali antara keduanya. Ini bukan selisih harga satuan. Harga satuannya $2 vs $0.10, selisih 20 kali. Jika memakai TTL 1 jam, sekali write $0.12, harga cache hit tidak berubah. Saat interval permintaan sering lebih dari 5 menit, bandingkan: biaya write tambahan ini dengan biaya membangun ulang prefix berulang kali, mana yang lebih murah.
Cara memeriksa tingkat cache hit Claude saat menggunakan APIYI
Pertama, hasil pengujian langsung. Pada 2026-10-26 kami menguji di APIYI dengan Claude Sonnet 5.5 sebanyak dua putaran: putaran pertama cache write 2523, read 0; putaran kedua setelah dikirim ulang apa adanya, cache read 2523, write 0, jumlah tokennya benar-benar cocok. Claude Opus 5.5 dengan prefix panjang juga bisa menulis dan bisa hit.
Namun tidak ada field diagnostics di respons. Tidak ada pada panggilan non-streaming, dan juga tidak ada di message_start pada panggilan streaming. Kami mengirim ulang sekali lagi dengan beta header, bahkan sengaja mengubah system untuk membuat cache miss sungguhan (read 0, write 2526), responsnya tetap tidak memuat field itu. Semua request mengembalikan 200, tanpa error. Kanal upstream pada lapisan proksi belum tentu jalur Claude API resmi, jadi dalam skenario proksi, kita terutama mengandalkan perbandingan dua field di usage.
| Gejala pemeriksaan mandiri | Penjelasan |
|---|---|
cache_read_input_tokens putaran ini persis sama dengan cache_creation_input_tokens putaran sebelumnya |
Prefix hit sepenuhnya |
| Read putaran ini jauh lebih kecil dari write putaran sebelumnya | Hanya bagian yang lebih depan yang hit, ada konten di tengah yang berubah |
| Write selalu 0 | Tidak ada penanda, panjang tidak cukup, atau memakai format kompatibel OpenAI |
| Putaran kedua menulis lagi, sedangkan read 0 | Prefix berubah, periksa timestamp, UUID, urutan serialisasi |
Selain itu perlu diperhatikan: cache hanya berlaku pada /v1/messages native. Kalau memanggil Claude dengan format kompatibel OpenAI /v1/chat/completions, bagaimanapun parameternya, biaya cache tidak akan didapat.
💡 Saran pemeriksaan: APIYI apiyi.com meneruskan
cache_controlapa adanya ke upstream, dan dua field cache di respons juga dikembalikan apa adanya, jadi kode tidak perlu penyesuaian tambahan untuk lapisan proksi. Jadikan “read putaran ini = write putaran sebelumnya” sebagai alert di log, dan itu bisa menggantikan sebagian besar pemeriksaan manual.
Keterbatasan diagnostics pada cache Claude
diagnostics bukan solusi untuk semua masalah. Pahami dulu batasannya sebelum digunakan:
- Hanya tersedia di API Claude resmi. Claude yang di-hosting di Amazon Bedrock dan Google Cloud tidak menyediakannya.
- Fingerprint hanya disimpan dalam jangka pendek, jadi kamu perlu mengirim permintaan secara berurutan dengan interval yang cukup singkat.
- Dua permintaan harus berasal dari organisasi dan workspace yang sama. Kamu bisa memverifikasinya lewat header respons
anthropic-workspace-id. - Pada percakapan panjang, jika perubahan tersembunyi jauh di dalam daftar pesan, hasilnya mungkin hanya mengembalikan
unavailable. - Ini adalah mekanisme best-effort. Kalau hasilnya tidak tersedia, permintaan tidak akan terblokir dan tidak akan gagal.
FAQ (Pertanyaan yang Sering Diajukan)
Q1: Kenapa diagnostics selalu bernilai null?
Ada tiga kemungkinan: objek `diagnostics` tidak disertakan; ini masih putaran pertama sehingga `previous_message_id` bernilai `null`; atau perbandingan sudah selesai dan tidak ada perbedaan. Padukan dengan pembacaan cache untuk menilai: jika angka bacaan tinggi berarti semuanya normal, sedangkan jika bacaannya 0 kemungkinan besar cache sudah kedaluwarsa. Kalau lewat layanan proksi, field-nya mungkin tidak dikembalikan sama sekali, jadi gunakan pemeriksaan mandiri lewat usage.
Q2: Apakah previous_message_not_found berarti permintaan berubah?
Bukan. Itu hanya berarti fingerprint yang sesuai tidak ditemukan. Ada tiga penyebab umum: putaran sebelumnya tidak menyertakan `diagnostics`, putaran sebelumnya berasal dari workspace lain, atau intervalnya terlalu lama. Sertakan `diagnostics` di setiap putaran dan persingkat intervalnya.
Q3: Apakah diagnostics dikenakan biaya tambahan?
Dokumentasi resmi tidak mencantumkan “biaya diagnostik” sebagai item terpisah; biayanya mengikuti permintaan Messages biasa. Dokumentasi juga tidak secara eksplisit menyatakan tanpa biaya tambahan, jadi silakan mengacu pada tagihan dan konsol untuk urusan penagihan.
Q4: Kalau lewat layanan proksi, apakah diagnostics masih bisa dipakai?
Pada pengujian kami di APIYI, field `diagnostics` tidak kami terima, tetapi penulisan dan pemuatan cache berjalan normal. Kamu bisa menilainya dengan melihat apakah “pembacaan putaran ini persis sama dengan penulisan putaran sebelumnya”. Cara integrasinya bisa dilihat di dokumentasi penagihan cache APIYI apiyi.com.
Q5: Sudah menulis cache_control, kenapa tidak pernah masuk ke cache?
Periksa tiga hal dulu: apakah `content` berupa string murni; apakah prefiks sudah mencapai 512 token (Sonnet 5.5 dan Opus 5.5); apakah kamu menggunakan format kompatibel OpenAI. Kalau salah satu dari ketiganya tidak terpenuhi, cache akan dilewati secara diam-diam.
Q6: Kalau muncul beberapa masalah sekaligus, mana yang harus diperbaiki dulu?
Perbaiki dulu yang dilaporkan oleh `cache_miss_reason`. Mekanisme ini hanya melaporkan titik percabangan paling awal; setelah diperbaiki, jalankan satu putaran lagi agar masalah yang sebelumnya terhalang bisa muncul. Memutar ulang permintaan yang sama berulang kali di APIYI apiyi.com bisa membantu mempersempit masalah satu per satu dengan cukup cepat.
Poin Penting Diagnostik Cache Claude
- Apa itu
diagnostics: Kirimidrespons dari putaran sebelumnya untuk menemukan segmen pertama tempat prefix bercabang - Cara mengaktifkan: Tambahkan
diagnosticsdi level teratas, isinullpada putaran pertama, lalu wajib dikirim di setiap putaran berikutnya - Arti
null: Pada putaran pertama atau saat tidak ada perbedaan, nilainya juganull— jangan langsung dianggap sebagai sinyal kegagalan - Cara menilai:
diagnosticsharus dibaca bersamacache_read_input_tokensbaru bisa ditarik kesimpulan - Syarat mutlak: Tandai secara eksplisit, capai 512 token, dan prefix harus identik byte per byte
- Selisih biaya: Prefix 30 ribu token dengan 200 panggilan per hari bisa membuat tagihan harian berbeda sekitar 17,8 kali
- Pemeriksaan mandiri via proksi: Di APIYI apiyi.com, cek apakah “pembacaan putaran ini sama dengan penulisan putaran sebelumnya”
Kesimpulan
Penelusuran tingkat cache hit Claude bisa diringkas menjadi tiga hal:
- Temukan titik percabangan: Sertakan
diagnosticsdi setiap putaran, bacacache_miss_reason, dan perbaiki dulu bagian yang dilaporkan paling awal - Penilaian silang: Lihat
diagnosticsdanusagesecara bersamaan —nullbukan berarti cache tidak berfungsi - Jaga syarat mutlak: Pasang penanda dengan benar, panjang mencukupi, riwayat hanya ditambahkan, serta
systemdantoolstetap stabil
Kalau jalur pemanggilan Anda tidak bisa mengakses diagnostics, bangun pemeriksaan mandiri menggunakan dua field di usage. Sebaiknya verifikasi angka baca-tulis cache lewat dua putaran permintaan di APIYI apiyi.com terlebih dahulu, baru kemudian diterapkan ke lingkungan produksi.
📚 Referensi
- Dokumentasi resmi Claude: Cache diagnostics: field diagnostik, enam tipe, dan matriks penilaian
- Tautan:
platform.claude.com -
Keterangan: Field, timeline, dan batasan diagnostics dalam artikel ini mengacu pada dokumen tersebut
-
Dokumentasi resmi Claude: Prompt caching: aturan cache, TTL, panjang minimum, dan harga
- Tautan:
platform.claude.com -
Keterangan: Sumber panjang minimum yang dapat di-cache dan tabel harga resmi
-
Daftar model APIYI: harga input, output, dan pembacaan cache untuk setiap model Claude
- Tautan:
docs.apiyi.com/models -
Keterangan: Data harga diperbarui pada 2026-10-25
-
Panduan penagihan cache Claude Prompt Caching APIYI: pengali, titik balik modal, dan kriteria pemeriksaan mandiri
- Tautan:
docs.apiyi.com/api-capabilities/claude-prompt-caching - Keterangan: Dasar penyelidikan dalam skenario layanan proksi API
Penulis: Tim Teknis APIYI
Diskusi teknis: Silakan hubungi kami melalui halaman utama situs APIYI, materi lainnya dapat diakses di pusat dokumentasi docs.apiyi.com
