Biaya Token Agen AI per Tugas: Formula, Catatan Biaya, dan Pengukuran

Ukur biaya per tugas yang selesai

Biaya token agen AI per tugas sebaiknya dihitung dari hasil yang benar-benar selesai, bukan dari jumlah prompt, jumlah percobaan, atau klaim penghematan umum. Rumus dasarnya sederhana: total biaya terukur untuk satu batch dibagi jumlah tugas yang selesai dan diverifikasi. Jika 100 tugas dicoba tetapi hanya 90 yang selesai sesuai definisi, pembaginya 90, bukan 100.

Definisi “selesai” harus dibuat sebelum pengukuran. Untuk tugas draf pesan, selesai bisa berarti draf muncul di kolom yang benar, penerima sudah dicek, dan keputusan kirim tetap terpisah. Untuk tugas kalender, selesai berarti acara tersimpan di kalender yang benar dengan waktu yang benar. Panduan Otomatisasi Tugas Multi-Langkah Android: Konfirmasi, Eksekusi, dan Pemulihan membantu memisahkan niat, langkah perangkat, dan titik verifikasi.

Biaya total juga perlu dipisah: penggunaan API model, langganan atau kredit bila berlaku, biaya alat eksternal, waktu tinjauan pengguna, dan energi tambahan bila Anda ingin menghitungnya. Jangan menghitung dua kali biaya yang sudah termasuk dalam paket atau kredit yang sama.

Bangun catatan biaya dari penggunaan penyedia model

Catatan biaya yang rapi memakai kategori yang tidak saling tumpang tindih. Untuk subtotal model, mulai dari input biasa yang tidak berasal dari cache, pembacaan cache, dan output tertagih. Biaya tambahan seperti penulisan cache, penyimpanan cache, grounding, pencarian, eksekusi alat, layanan eksternal, atau alokasi langganan ditambahkan terpisah hanya saat kategori itu benar-benar muncul di tagihan.

Dokumentasi Gemini tentang token menjelaskan bahwa token dapat mencakup teks dan modalitas lain seperti gambar, serta rincian penggunaan respons dapat mencantumkan input, output, token penalaran, dan konteks cache. Dokumentasi harga Gemini API juga menunjukkan bahwa tarif berbeda menurut model, modalitas, dan tier layanan; sebagian output dapat mencakup token penalaran, sementara caching atau grounding dapat punya biaya tersendiri.

Untuk cache, dokumentasi Claude tentang prompt caching berguna sebagai contoh akuntansi: ada input biasa, penulisan cache, dan pembacaan cache. Cache hanya membantu bila konten yang memenuhi syarat benar-benar dipakai ulang; perubahan awalan atau kondisi yang tidak sesuai dapat membuat cache tidak terpakai. Karena itu catatan biaya harus memakai rincian penggunaan dari penyedia, bukan asumsi.

Formula praktisnya: subtotal model = (input biasa / satu juta x tarif input per juta token) + (pembacaan cache / satu juta x tarif baca cache per juta token) + (output tertagih / satu juta x tarif output per juta token). Total biaya = subtotal model + biaya tambahan yang berlaku, seperti penulisan cache, penyimpanan cache, alat eksternal, atau alokasi langganan. Masukkan semua percobaan ulang dan percobaan gagal satu kali dalam total penggunaan; jangan menambahkan percobaan ulang lagi di luar angka penggunaan yang sudah mencakupnya.

Hitung ulang satu batch hipotetis

Contoh berikut adalah catatan biaya hipotetis untuk latihan hitung, bukan harga vendor atau harga FoneClaw. Misalnya satu batch tugas menghasilkan satu juta token input biasa, 200.000 token pembacaan cache, dan 150.000 token output tertagih. Tarif latihan yang dipakai: $2 per 1 juta input biasa, $0,20 per 1 juta pembacaan cache, dan $8 per 1 juta output.

Jika dari 100 tugas yang dicoba ada 90 tugas selesai dan terverifikasi, biaya per penyelesaian adalah $3,34 / 90 = sekitar $0,0371. Semua panggilan, percobaan ulang, dan kegagalan sudah termasuk dalam volume token di atas. Jika ada penulisan cache, penyimpanan cache, biaya langganan yang perlu dialokasikan, atau alat berbayar lain, tambahkan sebagai baris terpisah.

Untuk gambar dan tangkapan layar, ikuti cara penyedia menagih modalitas itu. Bila token gambar sudah masuk dalam input, jangan menambahkan “biaya gambar” kedua kecuali penyedia memang menagih kategori tambahan. Bila output sudah mencakup token penalaran dalam kategori tertagih, jangan menghitung penalaran lagi di luar output.

Apa yang bisa berubah saat eksekusi ada di ponsel

Eksekusi di ponsel dapat mengubah jumlah konteks, percobaan ulang, dan panggilan model yang diperlukan, tetapi tidak otomatis berarti biaya nol atau semua pemrosesan terjadi lokal. Di FoneClaw, model yang dikonfigurasi membantu memahami dan merencanakan, sementara FoneClaw menjalankan tindakan Android yang didukung pada aplikasi dan keadaan layar yang tersedia. Jika memakai model online yang dikonfigurasi, konteks yang Anda berikan dapat diproses oleh penyedia model. Pembahasan AI Agent Trust: Kontrol Lokal di Ponsel vs Keamanan Cloud menjelaskan perbedaan antara kendali perangkat dan pemrosesan model.

Contoh yang lebih konkret: pengguna meminta draf balasan pelanggan. FoneClaw dapat membaca keadaan layar yang terlihat pada aplikasi yang didukung, membantu mengisi kolom edit yang teridentifikasi, lalu membiarkan pengguna meninjau penerima dan isi. Pengisian teks tidak mengirim pesan, tidak menekan Submit, dan tidak menekan Enter. Jika layar berubah, keadaan perlu dibaca ulang sebelum langkah berikutnya.

Informasi struktur layar dan tangkapan layar juga bukan kategori biaya yang selalu lebih murah atau lebih mahal satu sama lain; hasilnya bergantung pada penyedia, cara penagihan, dan jenis tugas. Tangkapan layar tidak sebaiknya dipakai sebagai jalan pintas umum untuk menemukan kontrol yang tidak tersedia lewat aksesibilitas. Alur kerja tersimpan dapat menyimpan langkah alat yang dapat digunakan kembali, tetapi itu bukan bukti bahwa tugas berikutnya tidak memakai model. Untuk cakupan tindakan yang tersedia, lihat halaman fitur FoneClaw.

Jalankan pengukuran kecil yang bisa diulang

Protokol kecil lebih berguna daripada klaim penghematan luas. Pilih satu tugas berisiko rendah yang sama, misalnya menyiapkan draf balasan tanpa mengirim. Jalankan 10 kali pada perangkat, aplikasi, input, akun, dan pengaturan persetujuan yang sama. Sebelum mulai, tetapkan definisi selesai: draf masuk di kolom yang benar, penerima benar, teks bisa ditinjau, dan tidak ada pengiriman otomatis.

1. Catat jumlah tugas yang dicoba dan jumlah yang selesai terverifikasi.
2. Ambil rincian penggunaan dari penyedia model bila tersedia: input biasa, pembacaan cache, penulisan cache bila ada, output, token penalaran, gambar, dan alat.
3. Catat percobaan ulang dan kegagalan, tetapi jangan menambah biaya percobaan ulang dua kali jika rincian penggunaan sudah mencakup semua panggilan.
4. Catat waktu tinjauan pengguna, jumlah persetujuan, dan koreksi manual.
5. Jika ingin menghitung energi, ukur konsumsi tambahan secara terpisah dari biaya token.

Bandingkan total biaya dibagi tugas selesai terverifikasi. Jika tidak ada tugas yang selesai, metrik biaya per penyelesaian tidak terdefinisi; jangan menyebutnya nol. Untuk memahami cara memeriksa hasil tindakan Android, baca AI Agent Mengontrol Ponsel Android: Dari Niat ke Tindakan yang Terverifikasi.

Kurangi pemborosan tanpa menghapus pemeriksaan

Pengurangan biaya yang sehat biasanya datang dari input yang lebih jelas, riwayat yang dibatasi, cache yang benar-benar terkonfirmasi, dan diagnosis sebelum mencoba ulang. Jika tombol tidak ditemukan atau layar berubah, periksa keadaan aplikasi dulu; jangan mengirim ulang prompt panjang tanpa tahu bagian mana yang gagal. Untuk runbook kegagalan, lihat Debug dan Pemulihan Kegagalan Agen Ponsel Android: Runbook Praktis FoneClaw.

Jangan menghemat dengan menghapus pemeriksaan penerima, izin, kalender, pembayaran, atau tindakan yang berdampak pada orang lain. Untuk energi, pakai rumus terpisah: watt-jam tambahan / 1000 dikali tarif listrik lokal per kWh. Simpan biaya token, waktu pengguna, dan energi sebagai kolom berbeda kecuali Anda sengaja mengonversinya dengan aturan yang konsisten.