Penjelasan caching prompt: ukur penghematan di GetVibe

Agen coding dan asisten multi-turn sering mengirim ulang system prompt, definisi tool, dan awalan percakapan yang sama. Caching dapat membuat token input yang berulang tersebut lebih murah, tetapi hanya jika model, endpoint, dan bentuk request mendukungnya. Caching tidak memberikan diskon pada output yang dihasilkan, dan mengulang teks yang mirip saja tidak cukup jika cache key berubah. Panduan ini memisahkan jalur otomatis bergaya OpenAI dari perilaku breakpoint eksplisit Claude.

Apa yang berubah pada tagihan?

Cache read dikenai tarif cached input, bukan tarif input biasa. Katalog model GetVibe memublikasikan dukungan cache dan harga cache bersama tarif model. Pada snapshot katalog yang diperiksa 3 Oktober 2026, contohnya mencakup $0.0055 input · $0.0274 output per 1 juta token untuk GPT-6 Luna dan $0.168 input · $0.84 output per 1 juta token untuk Claude Sonnet 5.5. Nilai harga ini dirender dari halaman model live. Periksa juga detail cache di sana; jangan berasumsi bahwa setiap model menggunakan multiplier atau kebijakan penulisan yang sama.

Estimasi sederhana untuk awalan yang berulang adalah: jumlah token input yang berulang dikalikan tarif input normal, dibandingkan dengan jumlah token input yang berulang dikalikan tarif cache read. Selisihnya adalah potensi penghematan input. Kurangi biaya cache write jika model tersebut mengenakannya. Usage request yang Anda amati diperlukan untuk mengubah estimasi ini menjadi hasil terukur.

Model yang kompatibel dengan OpenAI: pertahankan awalan tetap stabil

Untuk rute keluarga OpenAI yang didukung, caching berlangsung otomatis. Tidak ada field cache-control yang perlu ditambahkan dalam request Chat Completions biasa. Bagian awal yang berulang harus tetap sama. Letakkan instruksi sistem, contoh yang stabil, dan definisi tool sebelum nilai khusus pengguna. Hindari menempatkan timestamp, ID acak, atau feature flag per request di bagian awal. Pertahankan urutan tool agar deterministik.

Jangan menulis ulang giliran percakapan sebelumnya saat melanjutkan sesi agen jika Anda mengharapkan awalan yang sama untuk cocok. Tambahkan giliran baru. Mengganti model akan memulai cache model yang berbeda. Sebuah request dapat valid dan tetap melaporkan tidak ada token yang di-cache karena awalan berada di bawah ambang cache model atau cache telah kedaluwarsa.

Claude: breakpoint dan endpoint Messages

Caching Claude menggunakan breakpoint cache-control. Integrasi GetVibe dapat menyisipkan breakpoint jika belum ada pada request Claude yang didukung; jika Anda mengelola breakpoint sendiri, periksa dokumentasi caching terbaru dan pertahankan marker pada bagian yang stabil. Claude Code menggunakan endpoint Anthropic Messages; panduan integrasi Claude Code menjelaskan base URL dan kredensialnya.

curl https://getvibeapi.com/v1/messages \
  -H "x-api-key: $GETVIBE_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-5.5",
    "max_tokens": 300,
    "system": [{"type":"text","text":"Stable instructions shared by every request."}],
    "messages": [{"role":"user","content":"A request-specific question."}]
  }'

Contoh ini menunjukkan bagian sistem yang stabil dan pesan pengguna yang berubah. Gunakan dokumentasi terbaru untuk field breakpoint yang tepat dan didukung oleh client serta model Anda.

Verifikasi cache hit, jangan hanya berasumsi

Kirim awalan panjang yang sama dua kali, dengan hanya mengubah suffix pendek. Periksa usage pada response. Response berbentuk OpenAI melaporkan input yang di-cache di bawah prompt_tokens_details.cached_tokens; response berbentuk Anthropic menampilkan field cache read dan cache creation. Halaman penggunaan akun juga dapat menampilkan informasi caching. Jika jumlah tersebut tetap nol, periksa kesamaan awalan, panjang minimum yang dapat di-cache, dukungan model, dan apakah Anda mengubah rute yang dipilih.

Gunakan sampel yang cukup besar untuk melampaui ambang cache model. System prompt satu kalimat mungkin tidak menghasilkan perbedaan yang terlihat. Bandingkan beberapa call berulang, karena masa berlaku cache dan penjadwalan request memengaruhi apakah awalan masih dalam kondisi warm.

Uji penghematan secara praktis

Pilih satu prompt nyata dengan awalan reusable yang cukup besar.
Catat usage input biasanya dan tarif terbaru pada halaman model.
Ulangi prompt tersebut dengan hanya mengubah suffix pengguna.
Pastikan response melaporkan input yang di-cache.
Bandingkan biaya ledger untuk request yang diulang.

Jaga panjang output tetap serupa selama eksperimen agar pengeluaran output tidak mengaburkan perubahan pada input. Jangan mengklaim penghematan hanya berdasarkan multiplier cache; verifikasi jumlah cache hit dan usage yang ditagihkan.

Cache miss yang umum

Timestamp atau ID request muncul sebelum instruksi yang stabil.
Definisi tool diserialisasi dalam urutan yang berbeda pada setiap request.
Aplikasi mengubah whitespace atau memotong history secara berbeda.
Model berubah di antara giliran.
Awalan terlalu pendek atau jendela cache telah berakhir.

Ketika caching berfungsi, percakapan agen yang panjang dapat menjadi lebih hemat, tetapi hal itu bukan alasan untuk mengirim konteks repository yang tidak perlu. Jaga prompt tetap fokus dan evaluasi total biaya tugas. Untuk detail endpoint yang lebih mendalam, baca panduan implementasi caching dan halaman harga live model.

Tempatkan breakpoint agar dapat digunakan kembali

Untuk prompt berformat Messages, pertahankan instruksi stabil dan materi referensi di system block, lalu letakkan pertanyaan yang berubah di user message. Cache breakpoint harus berada di akhir bagian yang stabil, bukan setelah timestamp khusus request. Jika konteks mencakup beberapa dokumen besar, tempatkan breakpoint di bagian yang digunakan kembali di antara call dan verifikasi jumlah breakpoint yang didukung model.

Berhati-hatilah dengan agen yang merangkum history mereka sendiri. Jika setiap giliran menulis ulang percakapan sebelumnya, awalan berubah dan cache hit dapat menghilang meskipun keseluruhan percakapan tampak serupa bagi manusia. Bandingkan body request yang diserialisasi saat men-debug miss, dengan tetap menjaga konten pribadi agar tidak masuk ke log.

Perhitungkan cache write dan panjang minimum

Beberapa model memerlukan panjang awalan minimum sebelum caching diterapkan, dan penulisan pertama dapat ditagihkan secara berbeda dari pembacaan berikutnya. Karena itu, prompt pendek mungkin tidak menunjukkan penghematan. Periksa harga cache read dan write model saat ini serta ambang token yang dapat di-cache. Kemudian bandingkan request pertama dengan request berikutnya secara terpisah, alih-alih merata-ratakannya menjadi satu angka yang tidak dapat dijelaskan.

Ketersediaan cache bergantung pada waktu. Awalan dapat kedaluwarsa setelah periode idle, dan cache bukan penyimpanan durable untuk data aplikasi. Jangan pernah mengandalkannya untuk mempertahankan state percakapan; terus kirim konteks yang diperlukan untuk mendapatkan jawaban yang benar.

Pisahkan penghematan cache dari optimasi prompt

Mengurangi konteks yang diduplikasi dan melakukan caching pada konteks yang berulang adalah dua perbaikan yang berbeda. Hapus terlebih dahulu instruksi yang tidak relevan, contoh yang sudah usang, dan log yang disalin. Kemudian cache materi stabil yang tersisa. Dengan begitu, prompt tetap lebih kecil bahkan saat cache miss dan Anda tidak perlu berulang kali membayar konteks yang tidak digunakan.

Saat mengevaluasi perubahan prompt, pertahankan contoh tugas tetap sama. Awalan yang lebih pendek dapat mengurangi biaya, tetapi juga menghapus informasi yang dibutuhkan model. Ukur kualitas output bersama usage yang di-cache dan yang tidak di-cache agar optimasi tersebut tidak diam-diam mengorbankan ketepatan.