Cara Mengurangi Tagihan API Claude (Opus 4.8 dan Fable 5)

Tagihan Claude Anda sebagian besar adalah token masukan, bukan keluaran. API ini tanpa status (stateless), jadi setiap giliran Anda mengirim ulang seluruh riwayat percakapan: prompt sistem, definisi alat, dokumen yang Anda tempelkan, dan setiap pesan sebelumnya. Dalam loop agen yang panjang atau sesi Claude Code, konteks yang dikirim ulang itu menumpuk dengan cepat, dan Anda membayarnya di setiap permintaan. Keluaran adalah bagian kecil dari tagihan.

Jadi, tuas yang benar-benar memengaruhi tagihan Anda adalah tuas yang mengecilkan apa yang Anda kirim, memotong tarif per-token, atau menghentikan Anda dari pengiriman ulang konteks yang tidak relevan. Panduan ini menjelaskan langkah-langkah konkretnya, dimulai dari solusi pihak pertama, kemudian proxy pihak ketiga (pxpipe) yang mengambil sudut pandang berbeda, dan terakhir di mana API tiruan (mock API) cocok saat Anda masih dalam tahap pembangunan.

Jika Anda ingin memahami dasar-dasar harga terlebih dahulu (cara kerja penghitung, apa itu token, bagaimana caching dan batching ditagih), penjelasan biaya API Claude kami membahas hal tersebut. Postingan ini tetap berfokus pada pemotongan tagihan, jadi kami tidak akan mengulang teori harga secara panjang lebar.

Tuas 1: Caching Prompt

Caching prompt adalah perubahan dengan pengembalian tertinggi untuk sebagian besar beban kerja agen. Anda menandai prefiks stabil (prompt sistem, definisi alat, dokumen referensi panjang) sebagai dapat di-cache, dan Claude menyimpannya. Pada permintaan berikutnya yang dimulai dengan byte yang sama, Anda membaca dari cache alih-alih membayar harga masukan penuh untuk memproses ulang.

Ekonominya kuat. Pembacaan cache berbiaya sekitar 0,1x dari tarif masukan dasar, sehingga Anda menghemat hingga ~90% pada bagian yang di-cache. Penulisan cache berbiaya lebih mahal dari token masukan normal: 1,25x untuk TTL 5 menit, atau 2x untuk TTL 1 jam. Premi penulisan itulah mengapa caching hanya menguntungkan saat Anda menggunakan kembali prefiks. Titik impas kira-kira 2 permintaan untuk cache 5 menit dan sekitar 3 untuk cache 1 jam. Jika sebuah prefiks hanya digunakan sekali dan dibuang, caching justru membebani biaya Anda; jika digunakan puluhan kali, itu hampir gratis setelah penulisan pertama.

Kendalanya adalah caching adalah pencocokan prefiks pada tingkat byte. Perubahan apa pun di dalam wilayah yang di-cache akan membuatnya tidak valid dan memaksa penulisan baru dengan harga penuh. Pelaku utamanya biasanya adalah variabel yang menyelinap ke bagian "stabil": stempel waktu di prompt sistem, ID sesi, penghitung permintaan, daftar alat yang diurutkan ulang. Itu terlihat stabil bagi Anda, tetapi terbaca sebagai byte baru oleh cache.

Verifikasi apakah caching benar-benar berfungsi. Baca usage.cache_read_input_tokens pada respons Anda. Pada permintaan berulang yang berbagi prefiks, angka tersebut harus besar dan bukan nol. Jika stuck di nol, ada sesuatu di prefiks Anda yang berubah di setiap panggilan, dan Anda membayar harga penuh sementara Anda yakin Anda di-cache. Untuk mekanisme apa yang di-cache dan mengapa, lihat apa itu prompt caching dan bagaimana cara kerjanya.

Tuas 2: Sesuaikan ukuran model

Pengeluaran berlebihan yang paling umum adalah menjalankan model yang lebih besar dari yang dibutuhkan tugas. Claude memberi Anda tangga harga yang jelas, dan perutean berdasarkan tugas alih-alih menggunakan satu model secara default seringkali merupakan penurunan item baris terbesar yang akan Anda dapatkan.

Berikut adalah harga per 1 juta token saat ini:

Beberapa hal yang dapat dibaca dari tabel tersebut. Fable 5 berharga 2x Opus 4.8 baik untuk masukan maupun keluaran, menjadikannya model yang paling mahal yang dirilis secara luas. Opus 4.8 memiliki jendela konteks 1 juta token penuh tanpa biaya premium konteks panjang, jadi Anda tidak membayar ekstra untuk memberinya basis kode yang besar. Sonnet 5 berjalan dengan harga perkenalan $2/$10 hingga 31-08-2026, kemudian beralih ke $3/$15. Haiku 4.5 adalah yang terendah dengan harga $1/$5, dengan jendela 200K yang lebih kecil.

Cocokkan model dengan tugasnya:

• Fable 5 untuk penalaran jangka panjang yang paling sulit di mana kemampuan ekstra benar-benar mengubah hasilnya. Menggunakan Fable secara default padahal Opus sudah cukup adalah cara paling umum tim menggandakan tagihan mereka tanpa alasan.
• Opus 4.8 untuk sebagian besar pekerjaan agen dan pengkodean. Ini adalah pilihan default yang masuk akal untuk Claude Code dan loop yang banyak menggunakan alat.
• Sonnet 5 untuk lalu lintas produksi bervolume tinggi di mana Anda membutuhkan kualitas yang baik dengan tarif lebih rendah.
• Haiku 4.5 untuk tugas sederhana atau yang membutuhkan kecepatan tinggi: klasifikasi, ekstraksi, perutean, balasan singkat.

Satu detail penagihan pada Fable 5: jika pengklasifikasi keamanan menolak permintaan, parameter beta fallbacks dapat mengarahkan ulang giliran tersebut ke Opus 4.8, dan giliran yang diarahkan ulang ditagih dengan tarif Opus. Itu biasanya diskon, bukan biaya tak terduga, tetapi penting untuk diketahui bahwa lalu lintas Fable Anda dapat menampilkan item dengan harga Opus.

Untuk rincian biaya yang lebih mendalam pada dua tingkatan harga yang mahal, lihat harga Opus 4.8, harga Fable 5, dan perbandingan langsung Fable 5 vs Opus 4.8 untuk mengetahui kapan kelipatan 2x itu sepadan. Jika Anda ingin mencoba tingkatan teratas dengan biaya rendah atau tanpa biaya saat Anda mengevaluasi, kami membahas menggunakan Opus 4.8 secara gratis dan memanggil API Fable 5 secara langsung.

Tuas 3: Batch API (Diskon 50%)

Jika pekerjaan Anda tidak memerlukan jawaban secara real-time, Batch API memangkas setiap token menjadi separuhnya. Anda mengirimkan pekerjaan ke /v1/messages/batches, pekerjaan tersebut berjalan secara asinkron, dan Anda mendapatkan hasilnya kembali. Sebagian besar batch selesai dalam satu jam; batas maksimumnya adalah 24 jam. Diskon 50% berlaku untuk semua penggunaan token pada batch tersebut, baik masukan maupun keluaran.

Kecocokannya sempit tetapi berharga. Batch adalah untuk pekerjaan yang bisa Anda tunggu:

• Menjalankan evaluasi di seluruh set pengujian.
• Klasifikasi atau ekstraksi massal atas backlog.
• Mengisi kembali ringkasan, tag, atau metadata yang berdekatan dengan embedding untuk catatan yang sudah ada.
• Pekerjaan offline besar apa pun di mana beberapa menit latensi tidak merugikan Anda.

Jika separuh pengeluaran Claude Anda adalah pemrosesan malam yang saat ini Anda jalankan melalui endpoint sinkron, memindahkannya ke batch adalah pemotongan langsung sebesar 50% pada separuh tersebut tanpa perubahan kualitas. Ini adalah kemenangan termurah dalam daftar ini untuk dipertimbangkan, karena satu-satunya pertukaran adalah latensi yang sebenarnya tidak Anda gunakan.

Tuas 4: Sesuaikan upaya, max_tokens, dan count_tokens

Tiga pengaturan mengontrol berapa banyak yang dapat dihabiskan oleh satu permintaan, dan mengaturnya dengan sengaja mencegah biaya melonjak.

Upaya (Effort). Parameter output_config.effort menerima low, medium, high, xhigh, atau max. Ini mengatur seberapa banyak model berpikir sebelum menjawab, dan token untuk berpikir itu ditagih. Upaya yang lebih rendah berarti lebih sedikit token berpikir dan keluaran. Banyak tugas yang dijalankan pada high karena kebiasaan menghasilkan jawaban yang sama pada medium atau low dengan biaya lebih rendah. Uji satu atau dua tingkat di bawah dan periksa apakah kualitasnya tetap terjaga.

max_tokens. Ini adalah batas keras pada keluaran. Ini tidak akan menurunkan biaya respons yang seharusnya singkat, tetapi ini membatasi kasus yang tak terkendali: model yang memutuskan untuk mengeluarkan esai 4.000 token padahal Anda menginginkan objek JSON. Atur ke batas yang masuk akal untuk tugas tersebut sehingga satu respons yang bertele-tele tidak dapat meledakkan satu item baris.

count_tokens. Perkirakan biaya sebelum Anda mengirim. Endpoint count_tokens memberi tahu Anda dengan tepat berapa banyak token masukan yang akan ditagih oleh sebuah permintaan, menggunakan tokenizer Claude sendiri. Jangan gunakan tiktoken untuk ini. Tiktoken adalah tokenizer OpenAI dan menghitung token Claude sekitar 15 hingga 20% lebih rendah, jadi menganggarkan berdasarkan itu berarti tagihan Anda yang sebenarnya akan jauh lebih tinggi dari perkiraan Anda. Jika Anda beroperasi mendekati anggaran per permintaan, count_tokens adalah cara Anda menangkap prompt yang terlalu besar sebelum membebani biaya Anda.

Tuas 5: Pangkas konteks yang Anda kirim ulang

Karena API ini tanpa status (stateless), loop agen yang panjang mengirim ulang seluruh riwayatnya setiap giliran, dan sebagian besar riwayat itu menjadi beban mati pada giliran ke-30: keluaran alat yang sudah Anda tindak lanjuti, eksplorasi yang sudah Anda lewati, file yang Anda baca sekali. Anda terus membayar harga masukan penuh untuk mengirim ulang semuanya.

Dua fitur sisi server memangkasnya untuk Anda:

• Penyuntingan konteks (clear_tool_uses_20250919) menghapus hasil alat yang usang dari konteks yang dikirim ulang, sehingga panggilan alat lama berhenti ditagih pada setiap giliran berikutnya.
• Pemadatan (Compaction) (compact_20260112) merangkum riwayat yang lebih lama ke dalam bentuk yang lebih singkat, sehingga percakapan panjang berhenti membawa transkrip mentah lengkapnya.

Keduanya berjalan di sisi server, yang berarti Anda tidak perlu membuat summarizer sendiri atau memotong array pesan secara manual. Khusus untuk sesi Claude Code yang berjalan lama, ini adalah tekanan yang sama di balik batas konteks di tengah tugas; panduan kami tentang jendela token Claude Code dan resetnya membahas bagaimana hal itu terjadi di editor. Inti dari penagihan ini sederhana: berhenti membayar untuk mengirim ulang konteks yang tidak lagi dibutuhkan model.

Melangkah lebih jauh: merender konteks sebagai gambar dengan pxpipe

Semua tuas pihak pertama mengecilkan atau mengubah tarif token yang Anda kirim. pxpipe menyerang biaya token masukan yang sama dari arah yang berbeda: ia merender konteks yang besar dan stabil sebagai gambar sehingga tokenisasinya lebih murah.

Apa itu. pxpipe adalah proxy lokal (berlisensi MIT, ditulis dalam TypeScript) yang berada di antara klien Anda dan Anthropic API. Anda mengarahkan ANTHROPIC_BASE_URL ke sana, dan ia memeriksa setiap permintaan saat keluar.

Bagaimana ini mengurangi biaya. Teks padat mahal per token. pxpipe menulis ulang bagian-bagian permintaan yang besar dan stabil (prompt sistem, dokumen alat, riwayat lama) menjadi gambar PNG yang ringkas sebelum permintaan meninggalkan mesin Anda. Konten padat berjalan sekitar 3,1 karakter per token gambar dibandingkan kira-kira 1 karakter per token teks, sehingga pencitraan konten tersebut dapat memangkas token masukannya dengan selisih besar. Proyek ini melaporkan contoh prompt sistem plus dokumen alat ~48k karakter yang menghasilkan sekitar 2,7k token gambar dibandingkan sekitar 25k sebagai teks. Pentingnya, ia menggunakan gerbang profitabilitas: ia hanya mencitrakan konten di mana perhitungan token benar-benar menguntungkan, dan prosa jarang melewati sebagai teks tanpa perubahan.

Instalasi dan jalankan. Dua perintah:

npx pxpipe-proxy

Itu akan memulai proxy di 127.0.0.1:47821. Kemudian arahkan Claude Code ke sana:

ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude

Dukungan model. Secara default, pxpipe mencitrakan permintaan untuk claude-fable-5 dan GPT 5.6. Opus 4.7/4.8 dan GPT 5.5 adalah fitur opt-in, karena proyek melaporkan bahwa mereka membaca konteks bergambar secara terukur lebih buruk. Anda mengaktifkannya dengan variabel lingkungan PXPIPE_MODELS (atau dasbor di URL proxy). Yang lainnya diteruskan tanpa perubahan.

Penghematan yang dilaporkan. Ini adalah angka yang dilaporkan sendiri dan tolok ukur dari proyek, bukan angka yang telah kami verifikasi secara independen. pxpipe melaporkan gambaran produksi berupa penghematan 59%, tagihan $100 turun menjadi sekitar $41 di seluruh 13.709 permintaan, dan uji coba SWE-bench Lite dengan ukuran permintaan -65%. Perlakukan ini sebagai tolok ukur vendor dan konfirmasikan pada lalu lintas Anda sendiri.

Pertukaran yang jujur. Pencitraan bukanlah uang gratis.

• Ini berinteraksi dengan caching prompt. Pencitraan mengubah byte permintaan, dan prefiks yang di-cache adalah pencocokan byte. Caching dan pencitraan sama-sama menargetkan biaya token masukan yang sama, sehingga keduanya dapat saling berlawanan: perubahan yang membuat pencitraan berhasil bisa menjadi perubahan yang mengubah wilayah cache Anda. Pendekatan mana yang lebih banyak menghemat tergantung pada prefiks spesifik Anda dan pola penggunaan ulang. Ukur keduanya pada beban kerja Anda sendiri daripada mengasumsi keduanya saling bertumpuk.
• Model membaca konteks bergambar melalui visi. Proyek itu sendiri menandai bahwa string padat (ID heksa panjang, token tepat) dapat salah dibaca, dan kesalahan pembacaan ini bersifat 'silent', bukan error. Verifikasi kualitas keluaran pada tugas Anda sendiri sebelum mempercayai penghematan tersebut.
• Ini adalah proxy pihak ketiga yang menangani lalu lintas Anda. Ini berjalan secara lokal, yang bagus, tetapi masih berada di jalur permintaan Anda. Evaluasilah terhadap postur keamanan Anda sendiri sebelum menggunakannya untuk lalu lintas produksi.

pxpipe layak diuji jika konteks Anda didominasi oleh blok besar, stabil, dan padat, serta Anda dapat memvalidasi kualitasnya. Untuk beban kerja yang jarang atau sangat ramah cache, tuas pihak pertama mungkin sudah menangkap sebagian besar keuntungan.

Pangkas token dev dan uji yang Anda buang saat membangun

Tidak ada yang di atas yang mengubah fakta bahwa Anda menghabiskan token sungguhan yang berbayar saat Anda masih membangun integrasi. Apidog tidak akan menurunkan tagihan produksi Claude Anda, dan tidak berpura-pura demikian. Tempatnya menghemat uang Anda adalah pada siklus dev dan pengujian.

Setiap kali Anda menjalankan integrasi Anda terhadap Anthropic API langsung selama pengembangan, setiap iterasi memakan token sungguhan: eksekusi yang gagal, percobaan ulang, pekerjaan CI yang aktif pada setiap push. Pengeluaran itu menumpuk saat Anda mengulang bentuk prompt, logika parsing, dan penanganan kesalahan, yang semuanya tidak memerlukan model sungguhan untuk divalidasi.

Mock respons Anthropic di Apidog sebagai gantinya. Definisikan kontrak permintaan dan respons untuk endpoint Claude yang Anda panggil, lalu arahkan tes dan CI Anda ke mock tersebut. Siklus Anda berjalan melawan tiruan deterministik yang mengembalikan bentuk yang Anda harapkan, dan Anda tidak menghabiskan token sama sekali untuk memvalidasi plumbing. Anda juga dapat merancang dan mendokumentasikan kontrak permintaan/respons tersebut di tempat yang sama, sehingga tim Anda menyetujui antarmuka sebelum siapa pun menghabiskan token untuk itu. Ini memangkas token dev dan uji yang Anda buang saat membangun, bukan tagihan produksi Anda. Itulah lingkup yang jujur.

Tumpuk tuas-tuas ini

Ini bukan pilihan antara satu atau yang lain. Pengurangan terbesar datang dari menumpuknya:

1. Cache prefiks stabil. Prompt sistem, alat, dokumen. Verifikasi cache_read_input_tokens bukan nol.
2. Rute berdasarkan tugas. Opus 4.8 sebagai default, Fable 5 hanya di mana itu mengubah hasil, Sonnet 5 untuk volume, Haiku 4.5 untuk pekerjaan sederhana.
3. Batch pekerjaan offline. Apa pun yang tidak sensitif terhadap latensi masuk ke /v1/messages/batches untuk diskon 50%.
4. Batasi setiap permintaan. Sesuaikan effort, batasi max_tokens, perkirakan dengan count_tokens.
5. Pangkas pengiriman ulang. Penyuntingan konteks dan pemadatan agar loop panjang berhenti membayar riwayat yang tidak terpakai.
6. Uji apakah pencitraan membantu. Jika konteks Anda besar dan padat, bandingkan pxpipe dengan caching pada prefiks Anda sendiri.
7. Mock saat membangun. Jaga agar siklus dev dan uji tidak terhitung pada meteran berbayar.

Mulailah dengan caching dan perutean model, karena kedua hal tersebut biasanya menyumbang sebagian besar penurunan. Ukur setelah setiap perubahan, karena satu-satunya angka yang penting adalah tagihan Anda yang sebenarnya.

Pertanyaan Umum (FAQ)

Apakah token masukan atau keluaran lebih mahal di tagihan Claude saya? Per token, keluaran lebih mahal daripada masukan di setiap model. Namun, untuk beban kerja agen dan pengkodean, sisi masukan biasanya merupakan tagihan yang lebih besar, karena API tanpa status membuat Anda mengirim ulang seluruh riwayat percakapan di setiap giliran. Itulah mengapa tuas terbesar menargetkan token masukan.

Apakah caching prompt atau Batch API yang lebih besar penghematannya? Tergantung pada beban kerja Anda. Caching menghemat hingga ~90% pada prefiks berulang dari lalu lintas interaktif, jadi ini unggul untuk chat dan loop agen yang menggunakan kembali prompt sistem. Batch memangkas 50% dari segalanya tetapi hanya untuk pekerjaan yang dapat Anda jalankan secara asinkron. Banyak tim menggunakan keduanya: cache jalur interaktif, batch pekerjaan offline.

Haruskah saya mengatur semuanya ke Fable 5 secara default? Tidak. Fable 5 berharga 2x Opus 4.8 dan ditujukan untuk penalaran jangka panjang yang paling sulit. Untuk sebagian besar pekerjaan agen dan pengkodean, Opus 4.8 memberi Anda hasil yang sama dengan setengah tarif masukan dan keluaran. Menggunakan Fable secara default padahal Opus sudah cukup adalah pengeluaran berlebihan yang paling umum.

Apakah pxpipe dapat digabungkan dengan caching prompt? Tidak secara bersih. Pencitraan mengubah byte permintaan, dan caching adalah pencocokan prefiks tingkat byte, sehingga keduanya menargetkan biaya token masukan yang sama dan dapat saling berlawanan. Uji keduanya pada prefiks aktual Anda dan ukur mana yang lebih banyak menghemat; jangan berasumsi keduanya akan saling menambah.

Apakah Apidog mengurangi biaya produksi Claude saya? Tidak. Apidog menirukan Anthropic API sehingga pengujian dan CI Anda mengenai tiruan alih-alih menghabiskan token berbayar saat Anda membangun. Itu mengurangi pengeluaran dev dan uji Anda, bukan tagihan produksi Anda.