Bayangkan perbaikan bug yang mengubah 12 baris. Agen membaca proyek, menyusun rencana, memulai agen pembantu, menjalankan pengujian, membaca kegagalannya, lalu mencoba lagi sebelum menghasilkan patch tersebut.
Tagihan mencakup setiap permintaan yang diperlukan untuk sampai ke hasil itu.
Hal itu membuat tugas singkat ternyata mudah sekali menghabiskan biaya berlebihan. Percakapan panjang dapat membawa file lama ke permintaan berikutnya. Sebuah alat dapat mengembalikan berlembar-lembar data, padahal keputusan berikutnya hanya membutuhkan satu catatan. Beberapa agen dapat mengulangi penyelidikan yang sama.
Anda dapat menemukan biaya ini di riwayat eksekusi. Mulailah dengan satu pekerjaan, lacak semua yang digunakannya, lalu periksa apakah hasilnya benar-benar berhasil. Setelah itu, ubah bagian yang melakukan pekerjaan yang tidak perlu.
1. Tetapkan biaya untuk tugas yang selesai
Pilih tugas yang Anda ulangi: memperbaiki bug yang dilaporkan, menyiapkan ringkasan riset, atau memeriksa sekumpulan catatan pelanggan. Tentukan kriteria penyelesaian sebelum menjalankannya.
Untuk perbaikan bug, penerimaan mungkin mensyaratkan pengujian yang mereproduksi kegagalan awal, hasil yang lolos setelah perubahan, serta tidak ada kegagalan dalam pengujian integrasi yang terdampak. Pesan yang menyatakan bug sudah diperbaiki tidak memenuhi syarat tersebut.
Beri tugas tersebut sebuah ID. Gunakan ID itu selama percobaan ulang, pengerjaan oleh agen asisten, verifikasi, dan hasil akhir. Catat ID permintaan terpisah untuk setiap pemanggilan model agar Anda dapat menemukan duplikat di log.
Perhitungan utamanya adalah:
Biaya per tugas yang diterima = total pengeluaran tercatat / jumlah tugas yang diterima
Sertakan percobaan yang gagal. Jika 10 tugas menghabiskan total $8 dan hanya 4 yang lolos, biayanya $2 per tugas yang diterima. Cantumkan tingkat penerimaan 40% di samping angka tersebut. Jika tidak ada yang lolos, laporkan pengeluaran dan nol tugas yang diterima; rasionya tidak terdefinisi.
Catat waktu perbaikan oleh manusia secara terpisah. Alur kerja yang menghemat $1 untuk biaya API tetapi membutuhkan 20 menit untuk dibereskan memiliki kompromi yang perlu diperhitungkan.
Untuk pekerjaan API, simpan respons penggunaan dari penyedia, ID model, tanggal harga, biaya alat, hasil tugas, dan stempel waktu. Jika data penggunaan tidak tersedia setelah waktu habis, tandai biayanya sebagai tidak diketahui dan cocokkan dengan catatan penyedia. Tidak adanya respons tidak membuktikan bahwa permintaan tersebut gratis. Jika masih ada permintaan yang belum diberi harga, tandai total kelompok tugas sebagai belum lengkap.
Pengguna Claude Code dapat memulai dengan /usage dan /context. Yang pertama membantu memeriksa penggunaan; yang kedua menunjukkan hal-hal yang mengisi percakapan. Dalam paket berlangganan, perkiraan dolar lokal bukan tagihan terpisah, dan jendela konteks berbeda dari batas kuota paket Anda.
2. Temukan konteks yang terus muncul kembali
Pesan terbaru Anda hanyalah sebagian dari permintaan model. Di Claude Code, permintaan juga dapat mencakup instruksi proyek, deskripsi alat, riwayat percakapan, isi berkas, dan hasil alat sebelumnya.
Misalkan dokumen 12,000 token yang tidak berubah muncul dalam 8 permintaan. Di seluruh pemanggilan itu, dokumen tersebut menyumbang 96,000 token masukan. Pembacaan cache yang memenuhi syarat mungkin dikenai tarif lebih rendah. Namun, dokumen itu mungkin tetap tidak relevan untuk beberapa keputusan tersebut.
Periksa urutan dalam satu tugas. Berkas apa saja yang dibaca? Keluaran apa yang tetap berada dalam percakapan? Permintaan mana yang menyebabkan kenaikan terbesar? Apakah agen masih menggunakan detail tersebut pada akhirnya?
Untuk bug pada total faktur, mulai dari masukan yang gagal, perhitungannya, fungsi yang memanggilnya, dan pengujian yang mencakup bagian tersebut. Biarkan agen menelusuri referensi saat membutuhkan informasi lebih lanjut. Memuat seluruh repositori sejak awal dapat membuat setiap giliran berikutnya membawa materi yang tidak pernah membantu perbaikan.
Simpan semua bukti lengkap di disk. Kembalikan hasil ringkas beserta jalur berkas dan detail yang cukup untuk memeriksa sumber aslinya. Untuk proses pengujian, sertakan perintah, kode keluar, nama pengujian yang gagal, kesalahan yang relevan, dan lokasi log.
Ringkasan yang menghilangkan satu-satunya petunjuk justru menambah pekerjaan. Pertahankan kesalahan persisnya, pengenal yang terdampak, dan bukti yang diperlukan untuk tindakan berikutnya.
3. Periksa apakah cache benar-benar bermanfaat
Caching prompt menggunakan kembali bagian awal permintaan yang cocok dan memenuhi syarat. Letakkan instruksi yang stabil terlebih dahulu, lalu data tugas yang berubah-ubah.
Dalam alur kerja Claude API khusus, stempel waktu sebelum batas cache dapat membuat entri berbeda di setiap pemanggilan. Letakkan batas setelah konten yang berulang. Periksa dokumentasi caching terbaru untuk model dan struktur permintaan Anda.
Bandingkan pembacaan dan penulisan cache antarpermintaan. Penulisan berulang dengan sedikit pembacaan menunjukkan bahwa Anda perlu memeriksa perubahan prefiks, panjang minimum yang memenuhi syarat, masa berlaku, dan waktu.
Pembacaan cache tetap membutuhkan biaya. Jumlah pembacaan yang tinggi bisa berarti caching berfungsi; periksa juga apakah konteks tersebut membantu menyelesaikan tugas.
Di Claude Code, subagen biasa memiliki konteks dan perilaku caching sendiri. Fork berperilaku berbeda. Kompaksi juga menggunakan permintaan model dan membangun ulang konteks percakapan. Hindari menjadwalkan kompaksi manual setiap beberapa menit tanpa mengukur hasilnya.
4. Perkecil keluaran alat
Respons alat dapat menjadi masukan untuk pemanggilan model berikutnya. Karena itu, respons yang besar dapat memengaruhi lebih dari sekadar permintaan yang awalnya mengambil data tersebut.
Ambil contoh laporan pesanan harian. Sebuah alat mengambil semua pesanan, model membaca setiap baris, lalu permintaan lain memintanya menghitung total. Skrip dapat memfilter catatan, menghitung total, dan mengembalikan pengecualian yang memerlukan penilaian.
Dengan begitu, yang diterima model berubah. Selain itu, Anda memiliki perhitungan yang bisa diuji secara terpisah.
Terapkan cara yang sama pada log, spreadsheet, dan hasil pencarian. Filter berdasarkan pelanggan, tanggal, kesalahan, atau jenis catatan yang relevan sebelum mengembalikan data. Sertakan filter yang digunakan, jumlah data yang diproses, apakah ada pemotongan data, serta jalur atau pengenal bukti asli.
Periksa paginasi. Memproses halaman pertama lalu menyajikannya sebagai seluruh kumpulan data akan menghasilkan jawaban salah yang lebih murah.
Hasil antara dapat tetap berada di lingkungan eksekusi, sementara data terpilih diteruskan ke model. Anda dapat menerapkan prinsip ini dengan skrip lokal kecil tanpa membangun sistem agen yang rumit.
Definisi alat juga mengisi konteks saat dimuat. Beberapa klien sudah menunda pemuatan definisi lengkap sampai diperlukan. Periksa konfigurasi Anda yang sebenarnya sebelum menghapus integrasi: jumlah koneksi saja tidak menunjukkan beban tokennya.
5. Simpan prosedurnya setelah Anda memahaminya
Perhatikan tugas saat agen berulang kali menemukan perintah yang sama, menulis ulang rencana yang sama, atau menentukan dari awal pengujian apa yang harus dijalankan.
Setelah prosedurnya dipahami, simpanlah. Masukkan instruksi khusus proyek ke dalam panduan singkat yang dapat digunakan kembali. Masukkan perhitungan tetap, transformasi berkas, dan urutan perintah ke dalam skrip yang sudah diuji.
Untuk bug faktur, skrip dapat menyiapkan data uji, menjalankan perhitungan, membandingkan nilai yang diharapkan, dan melaporkan hasilnya. Agen tetap perlu mendiagnosis ketidakcocokan yang tak terduga dan memilih perbaikan yang tepat. Namun, agen tidak perlu merancang perintah pengujian setiap kali.
Pastikan prosedur tetap sesuai dengan asumsi-asumsinya. Catat dependensi yang diperlukan, masukan yang diharapkan, dan kondisi yang mengharuskannya berhenti. Saat lingkungan berubah, kegagalan yang terlihat lebih mudah didiagnosis daripada pesan sukses yang tampak meyakinkan.
Pemeriksaan status berulang perlu ditangani dengan cara yang sama. Jika layanan menyediakan ID pekerjaan, gunakan peristiwa penyelesaian atau fungsi polling dengan batas waktu. Kembali ke model saat pekerjaan selesai, gagal, atau melewati tenggatnya.
Tindakan yang membuat atau mengirim sesuatu memerlukan kehati-hatian ekstra saat dicoba ulang. Periksa apakah percobaan pertama berhasil sebelum mengulanginya. Jika didukung, gunakan kembali kunci idempotensi untuk mencegah satu respons yang tidak pasti berubah menjadi dua pesanan atau dua pesan.
6. Beri setiap agen tugas yang berbeda
Agen paralel dapat mengurangi waktu pengerjaan. Pemanggilan, konteks, dan koordinasinya juga menambah total biaya.
Bagi pekerjaan jika tugas-tugasnya saling independen dan hasilnya mudah digabungkan. Satu agen dapat mereproduksi bug yang dilaporkan, sementara agen lain memeriksa kontrak antarmuka yang terdampak. Berikan masing-masing pertanyaan yang jelas dan hasil yang ditentukan.
Hindari memberi beberapa asisten instruksi umum yang sama untuk memeriksa semuanya. Hal itu dapat menghasilkan beberapa salinan penyelidikan yang sama, lalu perlu satu putaran lagi untuk menyelaraskan ringkasannya.
Serah terima yang baik menyebutkan tugas, berkas yang relevan, perubahan yang diizinkan, keluaran yang diharapkan, dan kondisi untuk berhenti. Minta lokasi bukti dan temuan yang diperlukan untuk langkah berikutnya. Simpan pekerjaan antara yang terperinci di berkas milik asisten.
Tentukan verifikasi dengan sengaja. Jalankan pemeriksaan terfokus selama implementasi, lalu jalankan pemeriksaan lebih luas yang diwajibkan pada hasil gabungan. Ulangi pemeriksaan jika kode berubah, proses sebelumnya gagal, atau ada bukti baru yang menjadi alasan. Catat alasan setiap pemeriksaan dijalankan.
Ukur perubahan model secara terpisah dari perubahan alur kerja. Gunakan kumpulan tugas dan pengujian penerimaan yang sama saat mencoba model atau pengaturan penalaran yang berbeda. Sertakan percobaan ulang dan waktu perbaikan dalam perbandingan. Harga per pemanggilan yang lebih rendah hanya bermanfaat jika keseluruhan pekerjaan tetap sepadan.
7. Baca kolom penggunaan dengan benar
Penyedia yang berbeda melaporkan masukan cache dengan cara yang berbeda. Menyalin rumus dari log satu penyedia ke log penyedia lain dapat menghasilkan tagihan yang tampak meyakinkan tetapi keliru.
Dalam respons Claude Messages standar, input_tokens, cache_creation_input_tokens, dan cache_read_input_tokens adalah kategori masukan yang terpisah. Pembuatan cache juga dapat dibagi berdasarkan masa berlaku. Sesuaikan setiap kategori dengan tarifnya.
Dalam skema OpenAI Responses saat ini, jumlah masukan yang di-cache dan jumlah penulisan cache yang berlaku termasuk dalam total masukan. Sebelum menetapkan harga masukan biasa, jumlah tersebut perlu dikurangi sesuai dokumentasi. Gunakan perhitungan penyedia untuk model dan API yang benar-benar Anda gunakan.
Simpan respons penggunaan asli bersama catatan yang telah dinormalisasi. Dengan begitu, Anda dapat memperbaiki perhitungan jika penyedia, model, atau harga berubah.
Beberapa fitur juga menghasilkan pekerjaan tambahan yang ditagihkan. Untuk kompaksi Claude API, jumlah masukan dan keluaran tingkat atas tidak mencakup iterasi kompaksi. Hitung harga entri dalam usage.iterations satu kali, dengan menggunakan kolom penggunaan pada setiap entri. Jangan tambahkan lagi jumlah tingkat atas.
Eksekusi alat, pencarian, hosting, dan penyimpanan dapat dikenai biaya terpisah. Sebut angka tersebut sebagai biaya model jika biaya-biaya itu tidak disertakan. Untuk permintaan streaming, gunakan total penggunaan akhir jika tersedia dan hindari menghitung pembaruan kumulatif berulang kali.
8. Kerjakan satu kelompok tugas
Berikut contoh perhitungan yang dapat Anda reproduksi. Jumlah permintaan, volume token, biaya alat, dan hasil di bawah ini adalah rekaan. Tidak ada agen yang dijalankan untuk menghasilkannya.
Dalam contoh ini, tugasnya mengambil tiga nilai beserta kutipan pendukung dari masing-masing empat dokumen. Hasil hanya dinyatakan lolos jika JSON, nilai, dan bukti sumbernya benar.
Kedua skenario menetapkan tiga hasil yang diterima, satu percobaan yang ditolak dan perlu diulang, serta satu tugas yang pada akhirnya gagal. Itu berarti lima percobaan untuk empat tugas. Setiap percobaan menambah biaya.
Skenario pertama mencakup 15 permintaan model: 375,000 token masukan yang tidak di-cache dan 15,000 token keluaran. Berdasarkan harga standar Claude Haiku 4.5 yang diperiksa pada 7 September 2026, biaya masukan adalah $1 per satu juta token dan biaya keluaran $5 per satu juta token. Biaya modelnya $0.45. Tambahkan $0.06 untuk biaya alat eksternal rekaan, sehingga totalnya $0.51.
Bagi $0.51 dengan tiga hasil yang diterima: $0.17 per hasil yang diterima.
Skenario kedua menetapkan 10 permintaan dengan lebih sedikit masukan baru dan sebagian masukan yang di-cache. Rincian biaya modelnya adalah sebagai berikut:
• 55,000 token masukan yang tidak di-cache dengan tarif $1 per satu juta: $0.055.
• 25,000 token penulisan cache lima menit dengan tarif $1.25 per satu juta: $0.03125.
• 25,000 token penulisan cache satu jam dengan tarif $2 per satu juta: $0.05.
• 50,000 token pembacaan cache dengan tarif $0.10 per satu juta: $0.005.
• 7,500 token keluaran dengan tarif $5 per satu juta: $0.0375.
Total biaya modelnya $0.17875. Tambahkan $0.05 untuk biaya alat eksternal rekaan: totalnya $0.22875 untuk semua percobaan, atau $0.07625 per hasil yang diterima. Masa berlaku cache yang beragam menunjukkan kategori perhitungan biaya; ini bukan konfigurasi yang disarankan.
Angka-angka ini menunjukkan biaya dari penggunaan yang dinyatakan. Angka tersebut tidak membuktikan bahwa memfilter konteks atau mengubah batas cache akan menghasilkan jumlah tersebut atau mempertahankan kualitas. Perbandingan nyata memerlukan catatan permintaan dan hasil yang diperiksa secara independen. Tugas yang gagal tetap harus dihitung dalam total.
9. Terapkan ini pada alur kerja Anda sendiri
Pilih sejumlah kecil tugas yang mewakili pekerjaan Anda dan jangan ubah masukannya. Sertakan keberhasilan biasa, kasus sulit, dan tugas yang pernah gagal. Tuliskan pemeriksaan penerimaan sebelum membuat perubahan.
Jalankan alur kerja yang ada dan simpan catatan permintaannya. Tandai bagian saat materi yang tidak diperlukan masuk ke percakapan, prosedur dibuat ulang, pemeriksaan duplikat dijalankan, atau kesalahan yang sama memicu percobaan lain.
Ubah satu mekanisme. Filter hasil alat yang besar. Simpan urutan perintah yang berulang. Perbaiki batas cache. Persempit tugas salah satu asisten. Untuk perbandingan tersebut, pertahankan model dan kriteria penerimaan yang sama.
Jalankan ulang masukan yang sama di lingkungan pengujian yang bersih. Bedakan proses awal dari proses dengan cache yang sudah terisi. Ulangi secukupnya untuk mengetahui apakah hasilnya konsisten, dan tetap sertakan percobaan yang gagal dalam total.
Gunakan perintah ini dengan agen pemrograman yang dapat mengakses implementasi dan log Anda:
Periksa alur kerja ini dan log eksekusi yang tersedia.
Tentukan batas tugas dan pemeriksaan penerimaan. Telusuri pemanggilan induk, pemanggilan asisten, percobaan ulang, verifikasi, dan hasil akhir.
Buat laporan lokal yang menunjukkan biaya model yang tercatat, biaya alat terpisah, data penggunaan yang hilang, tugas yang diterima, tugas yang gagal, waktu pengerjaan, dan intervensi manusia. Gunakan kolom penggunaan khusus penyedia yang terbaru dan daftar tarif bertanggal. Simpan respons penggunaan mentah. Hilangkan duplikasi ID permintaan.
Temukan biaya terbesar yang dapat dihindari berdasarkan bukti di log. Tunjukkan pemanggilan spesifik dan jelaskan mengapa pekerjaan tersebut tidak diperlukan. Pisahkan perkiraan dari jumlah yang tercatat.
Usulkan satu perubahan dan perbandingan yang menggunakan masukan, model, dan pemeriksaan penerimaan yang sama. Pisahkan proses awal dari proses dengan cache yang sudah terisi. Hentikan jika bukti yang diperlukan tidak tersedia, lalu sebutkan tepatnya bukti yang dibutuhkan.
Jangan lakukan pemanggilan API berbayar atau mengubah alur kerja aktif selama pemeriksaan ini. Simpan laporan dan usulan patch untuk ditinjau.
Pemeriksaan penerimaanlah yang menjaga kejujuran perbandingan. Jika pemfilteran log menyembunyikan kegagalan atau model yang lebih kecil memerlukan perbaikan berulang, catat hasil itu dan revisi perubahannya.
Saya membagikan alur kerja AI yang praktis di sini. Ikuti saya untuk bahasan berikutnya.