Caching prompt

Caching prompt upstream memungkinkan sebagian input Anda dilayani dari cache alih-alih dihitung ulang. Saat cache hit terjadi, bagian prompt yang ter-cache ditagih dengan diskon, bukan harga penuh. Halaman ini menjelaskan cara menyusun request agar cache benar-benar kena.

Caching dikunci pada prefix prompt Anda. Provider upstream menyimpan prefix prompt yang baru saja dilihat dan, ketika request berikutnya diawali prefix yang sama, melayani bagian itu dari cache. Bagian yang cocok dengan cache disebut cache read; bagian yang harus dihitung ulang dari awal disebut fresh input.

Aturan terpenting: letakkan konten stabil di awal prompt dan konten dinamis di akhir. Karena caching mencocokkan prefix, perubahan apa pun di awal prompt membatalkan seluruh jendela cache.

• Jaga system prompt, instruksi bersama, dan konteks referensi tetap stabil dan berada di atas.
• Letakkan data per-request — timestamp, ID, pertanyaan pengguna, dokumen hasil pencarian — di bagian bawah.
• Hindari menyisipkan timestamp atau nonce di dekat awal prompt.
• Pada percakapan multi-turn, jaga urutan riwayat percakapan dan tambahkan turn baru, jangan menulis ulang turn sebelumnya.

Pada endpoint Anthropic Messages, caching bersifat opt-in: Anda menandai breakpoint dengan field cache_control. Breakpoint memberi tahu provider di mana prefix yang bisa di-cache berakhir, sehingga prefix sebelumnya dapat dipakai ulang pada request berikutnya.

{
  "model": "<public-name>",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Anda adalah asisten yang membantu dengan blok instruksi besar yang stabil.",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "Pertanyaan pengguna yang dinamis di sini." }
  ]
}

Pada route yang kompatibel OpenAI, caching berjalan otomatis — Anda tidak perlu mengirim header opt-in apa pun. Provider melakukan caching berdasarkan stabilitas prefix saja, jadi panduan di atas tetap berlaku: letakkan konten stabil lebih dulu dan konten dinamis di akhir.

Tidak semua model atau route mendukung prompt caching, dan detailnya berbeda antar provider. Time-to-live (TTL) cache, ambang minimum token, serta endpoint mana yang mendukung caching semuanya spesifik per provider dan dapat berubah tanpa pemberitahuan. Jangan berasumsi model tertentu melakukan caching — verifikasi untuk beban kerja Anda.

Untuk memastikan caching berjalan, periksa rincian penggunaan di dashboard Anda. Jika Anda butuh nilai TTL atau ambang minimum yang pasti untuk model tertentu, tanyakan ke reseller Anda untuk angka terkini.