Biaya AI di Produksi Ditentukan Desain Prompt, Bukan Pilihan Model: Panduan Prompt Caching untuk Engineer

Ketika tagihan AI perusahaan naik, reaksi pertama biasanya sama: cari model yang lebih murah. Padahal di sistem produksi, penentu biaya terbesar sering bukan model yang dipilih, melainkan cara prompt disusun. Sebuah agen yang bekerja 40 giliran mengirim ulang seluruh percakapan di setiap giliran, sehingga biaya satu tugas tumbuh mendekati kuadrat dari jumlah giliran. Prompt caching tidak menghentikan pengiriman ulang itu, tetapi menurunkan harganya secara drastis untuk bagian yang sudah pernah dikirim. Dalam pengukuran yang dipublikasikan Anthropic, caching memangkas biaya loop agen dengan faktor 2,5 sampai 3,7 pada tingkat cache hit 81 sampai 90 persen.

Artikel ini ditulis untuk engineer yang menjalankan AI di produksi, dengan ringkasan di awal supaya pengambil keputusan tetap bisa memakainya. Angka dan perilaku di bawah merujuk ke API Anthropic. Penyedia lain punya skema berbeda (ada yang otomatis tanpa penanda, ada yang menagih penyimpanan per jam), jadi cek dokumentasinya sebelum menyalin asumsi ini.

Ringkasan untuk pengambil keputusan

• Membaca dari cache dihargai sekitar 10 persen dari harga input normal. Menulis ke cache dikenai premi satu kali: 1,25 kali (umur 5 menit) atau 2 kali (umur 1 jam).
• Dua atau tiga request dengan prefix yang sama sudah cukup untuk balik modal.
• Kegagalan paling mahal adalah yang senyap: request tetap sukses, hanya tagihannya yang naik. Buktinya ada di angka penggunaan (usage), bukan di kode.
• Urutan tuas biaya: yang gratis dulu (caching, batch, kebersihan input), baru yang menukar kualitas (effort, model).

Satu aturan yang menentukan semuanya: prefix match

Cache dicocokkan dari byte prompt yang sudah dirender, mulai dari awal sampai penanda cache_control. Satu byte yang berbeda di posisi N membatalkan semua yang datang setelahnya. Urutan render selalu sama: definisi tool, lalu system prompt, lalu pesan. Konsekuensinya sederhana: yang paling stabil harus paling depan, yang paling sering berubah paling belakang.

Kalau sebuah stempel waktu diselipkan di header system prompt, semua yang mengikutinya tidak bisa di-cache, berapa pun penanda yang dipasang. Empat pola penempatan yang paling sering dipakai:

• System prompt besar yang dipakai banyak request: pasang penanda di blok system terakhir. Tool dan system tersimpan bersama.
• Percakapan multi-giliran: pasang penanda di blok terakhir giliran terbaru, atau nyalakan caching otomatis di level request. Setiap giliran membaca seluruh riwayat sebelumnya.
• Prefix sama, akhiran berbeda: pasang penanda di akhir bagian yang dibagi bersama, bukan di akhir seluruh prompt. Kalau tidak, setiap request menulis entri baru dan tidak pernah ada yang dibaca.
• Prompt yang berubah sejak byte pertama: jangan di-cache. Anda hanya membayar premi tulis tanpa pernah membaca.

Batasnya empat penanda per request. Untuk agen yang berjalan panjang, kombinasi yang kuat adalah satu penanda eksplisit di akhir system prompt yang statis, ditambah caching otomatis untuk ekor percakapan yang terus tumbuh.

Angka yang perlu dihafal

Titik impas dihitung dari total biaya. Dengan umur cache 5 menit, dua request sudah cukup: 1,25x ditambah 0,1x menjadi 1,35x, dibanding 2x tanpa cache. Dengan umur 1 jam, dibutuhkan tiga request: 2x ditambah 0,2x menjadi 2,2x, dibanding 3x. Pada model kelas atas terbaru, harga baca turun lebih jauh lagi, menjadi US$0,25 per juta token, yaitu 0,025 kali harga input normal. Setiap perhitungan titik impas bergeser mengikuti angka itu.

Ada tiga detail yang sering terlewat:

• Ukuran minimum prefix berbeda per model. Pada model terbaru cukup 512 token, tetapi sebagian model generasi sebelumnya mensyaratkan sampai 4.096 token. Angkanya tidak naik atau turun teratur antar generasi. Prompt 3.000 token bisa ter-cache di satu model dan diam-diam tidak di model lain, tanpa pesan error apa pun, hanya cache_creation_input_tokens yang bernilai nol.
• Membaca cache menyegarkan timernya tanpa biaya tambahan. Umur dihitung dari awal request, bukan dari akhirnya, jadi waktu generasi ikut memakan jatah.
• Cache terikat pada workspace. Lalu lintas untuk prompt yang sama yang terpecah ke beberapa workspace menulis dan membaca entri yang terpisah. Cek ini sebelum menyalahkan prompt karena hit rate rendah.

Pilih umur cache dari jeda antar request, bukan firasat

Ukur jeda dari awal satu request ke awal request berikutnya yang memakai prefix sama. Kalau jedanya selalu di bawah 5 menit, umur 5 menit menyegarkan dirinya sendiri di setiap request dan itu pilihan yang lebih murah. Umur 1 jam hanya terbayar pada jendela 5 sampai 60 menit, misalnya pengguna yang membalas 20 menit kemudian atau tugas sampingan yang lama. Di atas satu jam, keduanya tidak menolong: hangatkan cache secara berkala atau terima miss pertama.

Untuk model kelas atas terbaru dengan harga baca 0,025x, ada pilihan yang biasanya lebih murah dari umur 1 jam: tetap di umur 5 menit, dan saat idle kirim ulang request terakhir dengan max_tokens: 0 sesaat sebelum entri kedaluwarsa. Request itu menyegarkan timer dan hanya menagih biaya baca yang sangat kecil, tanpa token keluaran.

Ada satu jebakan konkurensi. Entri cache baru bisa dibaca setelah respons pertama mulai mengalir. N request paralel dengan prefix identik semuanya membayar penuh. Untuk pola fan-out, kirim satu request dulu, tunggu token pertamanya, baru luncurkan sisanya.

Lima cara cache mati tanpa ada yang tahu

Semua penyebab ini berbagi satu ciri: request tetap sukses. Karena itu tidak ada alarm yang berbunyi sampai seseorang membuka tagihan.

Dua hal tambahan yang layak diwaspadai. Pertama, jendela pencarian mundur setiap penanda hanya 20 posisi. Sebuah giliran yang menambah lebih dari 20 posisi konten (urutan panjang tool berantai, banyak gambar) bisa mendorong entri sebelumnya keluar dari jendela, dan seluruh percakapan ditulis ulang di setiap request meski payload-nya identik byte demi byte. Perbaikannya: pasang penanda perantara kira-kira setiap 15 posisi. Kedua, perubahan konfigurasi thinking atau effort membatalkan cache pesan, dan pada sebagian model juga cache tool dan system. Tetapkan keduanya per rute, jangan divariasikan per request.

Verifikasi dari angka usage, bukan dari kode

Tiga field pada usage adalah satu-satunya bukti bahwa caching bekerja: cache_creation_input_tokens (token yang ditulis, dikenai premi), cache_read_input_tokens (token yang dibaca dari cache), dan input_tokens (sisa yang dibayar penuh). Jumlah ketiganya adalah ukuran prompt yang sebenarnya. Melihat input_tokens saja menyesatkan: agen yang berjalan berjam-jam bisa tampak hanya memproses 4 ribu token karena sisanya dilayani dari cache.

Loop yang sehat punya tanda tangan yang jelas. Pada setiap request, cache_read_input_tokens mencakup seluruh riwayat sebelumnya dan terus tumbuh, cache_creation_input_tokens kira-kira hanya sebesar keluaran dan masukan terakhir, dan input_tokens hanya ekor setelah penanda terakhir. Kalau angka penulisan mendekati ukuran seluruh percakapan di setiap request, ada sesuatu di hulu yang merusak prefix.

Kegagalan produksi yang paling mahal hampir selalu berupa regresi, bukan implementasi awal yang keliru. Caching bekerja saat pertama dibuat, lalu sebuah perubahan susunan prompt sebulan kemudian (satu field dinamis baru, sebuah fitur yang menulis ulang riwayat, daftar tool yang urutannya tak lagi tetap) membuat semua request miss dan tidak ada yang sadar berbulan-bulan. Karena itu, pasang pemeriksaan yang berdiri sendiri: tes integrasi yang mengirim request identik dua kali dan menegaskan bahwa cache_read_input_tokens lebih dari nol pada yang kedua, atau pemantauan pada ketiga field itu.

Untuk melacak penyebab, bandingkan payload dari request berurutan setelah membuang penanda cache_control (penanda yang bergerak selalu berbeda dan bukan penyebab). Divergensi pertama di bagian yang seharusnya identik adalah titik pembatalan. Anthropic juga menyediakan diagnostik cache (beta) yang menyebutkan di mana dua request berbeda tanpa perlu mencatat payload.

Yang kami pelajari dari agen internal

Kami menjalankan agen AI untuk pekerjaan internal, dan dua keputusan berikut terbukti lebih menentukan biaya daripada pilihan model.

Batasi pekerjaan kecil menjadi satu panggilan model tanpa tool. Untuk tugas penalaran sekali jalan, misalnya menganalisis satu pesan masuk lalu menyarankan tindakan, kami memakai satu panggilan terbatas: prompt sistem pendek, tanpa akses tool, tanpa akses berkas atau shell. Biaya per panggilan tercatat sekitar 1 sampai 5 sen dolar, dan perilakunya mudah diprediksi. Ada detail yang menggigit di sini. Tool dimatikan dengan daftar tool yang kosong, bukan dengan daftar izin yang kosong, karena yang kedua hanya mengatur persetujuan otomatis dan tool tetap tersedia. Kami juga sempat membatasi jumlah giliran ke satu dan gagal, sebab jumlah giliran yang dipakai SDK bervariasi tanpa terdokumentasi. Batas lima giliran menyelesaikannya.

Selaraskan jendela kesegaran sesi dengan perilaku cache. Percakapan dengan agen bisa dilanjutkan. Kami melanjutkan sesi yang aktif dalam satu jam terakhir dan memulai sesi baru setelahnya. Alasannya ekonomi cache: selama cache masih hangat, melanjutkan riwayat panjang hampir gratis. Setelah dingin, riwayat panjang itu dibayar penuh pada giliran pertama, sehingga sesi baru lebih murah. Tombol manual untuk memulai sesi baru tetap tersedia kapan saja.

Urutan tuas biaya: yang gratis dulu

Biaya AI sebaiknya dioptimalkan dalam satuan biaya per tugas yang selesai, bukan biaya per token atau per request. Model yang lebih mahal per token bisa menjadi yang lebih murah kalau menyelesaikan pekerjaan dengan lebih sedikit giliran. Model murah yang gagal tetap menagih token-nya, lalu percobaan ulangnya, lalu apa pun akibat kegagalan itu di hilir.

Tuas gratis dikerjakan lebih dulu karena tidak menurunkan kualitas keluaran:

• Caching: tuas terbesar pada setiap model dan tolok ukur yang diukur Anthropic. Sekali menyala, tugasnya tinggal menjaganya tetap sehat.
• Kebersihan input: pindahkan dokumen referensi besar ke balik tool supaya diambil sesuai kebutuhan, hapus ringkasan tool yang hanya mengulang skema, dan kecilkan gambar. Gambar dihitung per luas piksel, kira-kira satu token per petak 28 kali 28 piksel, sehingga 1280 kali 720 berhenti di sekitar 1.200 token.
• Output dan loop: max_tokens adalah pagar, bukan tuas. Model tidak melihatnya, dan respons yang terpotong adalah percobaan yang gagal. Atur panjang keluaran lewat bentuk yang diminta di prompt, dengan contoh.
• Batch: diskon 50 persen untuk semua token, termasuk baca dan tulis cache, untuk pekerjaan yang tidak ditunggu siapa pun. Hasil datang dalam 24 jam.

Baru setelah itu tuas yang menukar kualitas, satu per satu dan diukur terhadap eval: turunkan effort dulu, lalu pertimbangkan model. Pada beban kerja riset dan pengetahuan, kurvanya hampir datar. Pada coding jangka panjang, ada pertukaran nyata. Jangan lupa bahwa prompt yang ditulis untuk model lama bisa membuat model baru bekerja berlebihan: dalam satu evaluasi Anthropic pada layanan dukungan pelanggan, prompt yang ditulis untuk model generasi sebelumnya menghabiskan 36 persen lebih banyak per tiket tanpa perubahan akurasi.

Penutup

Biaya AI yang sehat adalah hasil dari disiplin susunan prompt dan kebiasaan memverifikasi, bukan kebetulan. Engineer yang menempatkan bagian stabil di depan, menjaga prefix tetap deterministik, dan menjadikan angka usage sebagai alarm akan membayar jauh lebih murah untuk kualitas yang sama, di model mana pun.

Jika tim Anda menjalankan agen AI di produksi dan ingin meninjau susunan prompt, jalur verifikasi cache, atau arsitektur biayanya, kami terbuka untuk diskusi awal.