| Komponen biaya | Harga publik Claude Opus 4.7 |
|---|---|
| Base input tokens | US$5 / 1 juta token |
| Output tokens | US$25 / 1 juta token |
| Cache write 5 menit | US$6,25 / 1 juta token |
| Cache write 1 jam | US$10 / 1 juta token |
| Cache hit / refresh | US$0,50 / 1 juta token |
Tanpa cache, rumus dasarnya sederhana:
biaya = input_tokens / 1.000.000 × 5
+ output_tokens / 1.000.000 × 25
Jika memakai prompt caching, pecah input menjadi dua bagian: konteks yang bisa dipakai ulang dan input baru. Bagian yang pertama kali ditulis ke cache 5 menit dihitung US$6,25/MTok, cache 1 jam dihitung US$10/MTok, lalu permintaan berikutnya yang mengenai cache dihitung US$0,50/MTok. Pertanyaan baru atau pesan baru yang tidak masuk cache tetap dihitung sebagai input biasa, dan jawaban model tetap dihitung sebagai output.
Kalau satu dokumen hanya dianalisis sekali dan tidak ada sesi tanya-jawab lanjutan, budget bisa langsung dihitung dari total token dokumen, system prompt, pertanyaan, dan jawaban. Contoh berikut memakai harga publik Claude API.
| Skenario | Input | Output | Estimasi biaya |
|---|---|---|---|
| Ringkasan dokumen panjang yang relatif pendek | 100 ribu | 5 ribu | sekitar US$0,625 |
| Analisis dokumen menengah-besar | 300 ribu | 8 ribu | sekitar US$1,70 |
| Analisis dokumen sangat besar | 1 juta | 10 ribu | sekitar US$5,25 |
Contoh 300 ribu input + 8 ribu output:
300.000 / 1.000.000 × 5 = 1,50
8.000 / 1.000.000 × 25 = 0,20
Total = US$1,70
Jika Anda pindah dari model lama ke Opus 4.7, jangan langsung menyalin estimasi token lama. Anthropic mencatat Opus 4.7 memakai tokenizer baru, dan jumlah token untuk teks tetap bisa naik hingga 35%.
Misalnya input yang dulu diperkirakan 300 ribu token dibuat lebih konservatif menjadi 405 ribu token. Dengan output 8 ribu token:
405.000 / 1.000.000 × 5 = 2,025
8.000 / 1.000.000 × 25 = 0,20
Total ≈ US$2,23
Untuk produk tanya-jawab dokumen, biaya yang sering luput bukan output, melainkan dokumen besar yang ikut dibayar lagi pada setiap pertanyaan. Kalau dokumen yang sama akan dipakai beberapa kali, prompt caching sebaiknya dihitung sejak desain awal.
Asumsi contoh:
| Cara kerja | Komponen biaya | Estimasi biaya |
|---|---|---|
| Putaran pertama, membuat cache 5 menit | 300 ribu × US$6,25/MTok + 2 ribu × US$5/MTok + 2 ribu × US$25/MTok | sekitar US$1,935 |
| Putaran berikutnya, cache hit | 300 ribu × US$0,50/MTok + 2 ribu × US$5/MTok + 2 ribu × US$25/MTok | sekitar US$0,21 |
| Tanpa cache, kirim ulang dokumen penuh | 302 ribu × US$5/MTok + 2 ribu × US$25/MTok | sekitar US$1,56 |
Dalam contoh ini, request pertama dengan cache memang lebih mahal daripada request tanpa cache karena ada biaya write. Namun begitu dokumen yang sama masuk putaran kedua, total biaya dengan cache sudah lebih rendah:
Tanpa cache, 2 putaran: sekitar 1,56 × 2 = US$3,12
Dengan cache 5 menit, 2 putaran: sekitar 1,935 + 0,21 = US$2,145
Jadi, angka pentingnya adalah cache hit rate: berapa persen request yang benar-benar memakai konteks yang sama, apakah pertanyaan lanjutan masih masuk dalam masa cache 5 menit atau 1 jam, dan apakah setiap putaran tetap membawa banyak konten baru yang tidak tercache.
Logika percakapan panjang sama seperti dokumen panjang. Jika aplikasi selalu mengirim riwayat chat besar ke model pada setiap putaran, biaya input akan naik cepat. Bagian riwayat yang stabil dan dipakai ulang layak dievaluasi untuk prompt caching.
Asumsi contoh:
| Cara kerja | Estimasi biaya |
|---|---|
| Tanpa cache: tiap putaran membawa 200 ribu riwayat + 1 ribu pesan baru + 2 ribu output | sekitar US$1,055 / putaran |
| Tulis 200 ribu riwayat ke cache 5 menit: putaran pertama | sekitar US$1,305 |
| Setelah cache 5 menit hit: tiap putaran | sekitar US$0,155 / putaran |
| Tulis 200 ribu riwayat ke cache 1 jam: putaran pertama | sekitar US$2,055 |
| Setelah cache 1 jam hit: tiap putaran | sekitar US$0,155 / putaran |
Pilihan 5 menit atau 1 jam jangan hanya dilihat dari harga write. Lihat perilaku pengguna:
Batch sering dipakai untuk pekerjaan offline seperti analisis banyak dokumen, pelabelan data, ringkasan massal, atau klasifikasi. Namun sebelum Anda memastikan akun, kontrak, atau endpoint yang dipakai memang mendapat batch pricing tertentu, jangan memasukkan diskon yang belum terverifikasi ke budget formal. Cara aman: hitung dulu dengan harga API sinkron publik, lalu turunkan jika harga batch yang benar sudah dikonfirmasi.
Rumus konservatifnya:
Total biaya = total input tokens / 1.000.000 × 5
+ total output tokens / 1.000.000 × 25
Contoh: 10.000 tugas, masing-masing 2 ribu input + 500 output.
Total input = 10.000 × 2.000 = 20.000.000 token
Total output = 10.000 × 500 = 5.000.000 token
Biaya input = 20 × 5 = US$100
Biaya output = 5 × 25 = US$125
Total = US$225
US$225 di sini adalah estimasi konservatif tanpa batch discount. Jika nanti ada harga batch yang valid untuk akun atau platform Anda, cukup ganti harga satuannya.
Perhatikan juga jalur akses. Jika tidak langsung memakai Anthropic Claude API, tetapi lewat platform cloud atau penyedia routing pihak ketiga, tagihan bisa berbeda. CloudPrice, sebagai sumber data pihak ketiga, mencantumkan Opus 4.7 untuk Anthropic / global pada US$5 input dan US$25 output per MTok, tetapi juga mencantumkan beberapa kode regional AWS Bedrock pada US$5,50 input dan US$27,50 output per MTok. Angka seperti ini berguna sebagai alarm pengecekan; untuk pengadaan resmi, tetap pakai halaman billing, kontrak, dan dokumentasi resmi platform yang Anda gunakan.
Spreadsheet biaya yang terlalu rapi biasanya terlalu optimistis. Setidaknya masukkan tiga hal ini ke buffer:
Sebagai pegangan non-resmi untuk budgeting:
| Tahap | Faktor anggaran yang disarankan |
|---|---|
| PoC / uji coba awal | nilai teori × 1,2 sampai 1,5 |
| Produksi dengan trafik relatif stabil | nilai teori × 1,35 sampai 1,6 |
| Migrasi dari model lama ke Opus 4.7 dan sangat bergantung pada konteks panjang | nilai teori × 1,5 sampai 1,8 |
Faktor di atas bukan harga resmi Anthropic. Anggap sebagai cara konservatif untuk menahan kejutan tagihan. Setelah sistem berjalan, isi ulang model budget dengan log token aktual, cache hit rate, dan data invoice.
Tanpa cache:
Biaya bulanan ≈ jumlah request harian × 30
× (rata-rata input tokens / 1.000.000 × 5
+ rata-rata output tokens / 1.000.000 × 25)
Dengan cache, jangan gabungkan semuanya menjadi input biasa. Pisahkan:
Biaya bulanan ≈ biaya input biasa
+ biaya cache write
+ biaya cache hit / refresh
+ biaya output
Variabel minimum yang sebaiknya Anda isi sebelum implementasi:
| Variabel | Contoh nilai |
|---|---|
| Rata-rata input per request | 300.000 token |
| Rata-rata output per request | 8.000 token |
| Request per hari | 1.000 |
| Cache write tokens | 300.000 per dokumen |
| Cache hit tokens | 300.000 per hit |
| Cache hit rate | 60% |
| Buffer tokenizer | sampai × 1,35 |
| Buffer operasional | misalnya × 1,35 sampai 1,6 |
Untuk analisis dokumen panjang sekali jalan, gunakan harga US$5/MTok input + US$25/MTok output.
Untuk dokumen yang sama yang akan ditanya berkali-kali, atau percakapan panjang yang selalu membawa riwayat besar, hitung prompt caching terlebih dahulu. Pada contoh dokumen 300 ribu token dengan pertanyaan 2 ribu token dan output 2 ribu token, cache hit 5 menit sekitar US$0,21 per putaran, dibanding sekitar US$1,56 jika dokumen penuh dikirim ulang setiap kali.
Untuk batch, mulai dari harga API sinkron publik agar budget tidak terlalu agresif, lalu revisi setelah harga batch, endpoint cloud, atau kontrak benar-benar jelas. Jika migrasi dari model lama ke Opus 4.7, kalikan estimasi input dengan buffer hingga 1,35 untuk risiko tokenizer, lalu tambahkan buffer operasional agar angka budget lebih dekat dengan tagihan nyata.