Agen AI dapat memakai 1.000 kali lebih banyak token—biaya tinggi belum tentu akurat

Agen AI dapat memakai jauh lebih banyak token daripada percakapan kode biasa, tetapi konsumsi tinggi tidak otomatis menghasilkan jawaban yang lebih akurat. Biaya paling efektif dikendalikan dengan membatasi langkah dan retry, mengurangi konteks berulang, mengukur cache hit, serta memakai model mahal hanya pada langkah yang memerlukannya.

Ukuran utamanya bukan sekadar harga per sejuta token, melainkan biaya per tugas yang berhasil. Agen yang murah per panggilan tetap dapat mahal jika mengulang alat, membaca data yang sama, terjebak dalam loop, atau menghasilkan pekerjaan yang harus diperbaiki manusia.

Mengapa konsumsi agen dapat melonjak

Satu permintaan kepada agen dapat berkembang menjadi rangkaian perencanaan, pembacaan berkas, panggilan alat, pemeriksaan hasil, dan percobaan ulang. Pada setiap langkah, sistem mungkin mengirim kembali instruksi, riwayat, definisi alat, serta potongan repositori atau dokumen. Karena itu, token input dapat bertambah jauh lebih cepat daripada jawaban akhir yang dilihat pengguna.

Studi delapan model pada SWE-bench Verified menemukan bahwa tugas agentik memakai 1.000 kali lebih banyak token daripada penalaran dan percakapan kode. Total pemakaian untuk tugas yang sama dapat berbeda hingga 30 kali antarrun; token input menjadi pendorong utama, sedangkan konsumsi yang lebih tinggi tidak otomatis meningkatkan akurasi dan akurasi sering memuncak pada biaya menengah sebelum mendatar.

Temuan itu berasal dari agen pengodean pada benchmark tertentu, bukan ukuran universal untuk semua agen. Namun, variasi antarrun menunjukkan bahwa satu percobaan dan tarif katalog model tidak cukup untuk memperkirakan anggaran produksi. Distribusi biaya, terutama run yang sangat panjang, perlu ikut diukur.

Benchmark vendor membandingkan sistem, bukan tarif API saja

Dalam benchmark internal Glean atas lebih dari 180 tugas perusahaan, perusahaan itu melaporkan biaya rata-rata US$0,58 per tugas untuk Glean Assistant dengan auto routing, dibandingkan US$2,98 untuk Claude Cowork yang ditetapkan memakai Claude Sonnet 5 dengan reasoning tinggi. Glean juga mencatat biaya token 81% lebih rendah, pemakaian 1,3 juta versus 4,4 juta token, dan preferensi penilai sebesar 78% untuk jawabannya.

Angka tersebut merupakan klaim vendor, bukan uji independen yang hanya mengganti satu model. Perbandingannya melibatkan dua sistem dengan akses konteks, konektor, harness, penyimpanan hasil alat, routing, dan model berbeda. Kueri dibuat secara sintetis berdasarkan pola penggunaan pelanggan, mengakses data produksi Glean, lalu respons dinilai berdampingan menggunakan skala preferensi lima poin.

Kesimpulan yang dapat dipertahankan bukan bahwa satu produk selalu 81% lebih murah. Benchmark itu menunjukkan bahwa arsitektur agen dapat memengaruhi jumlah token sekaligus tarif campuran token. Dampaknya harus diuji kembali menggunakan tugas dan ambang kualitas milik organisasi sendiri.

Ubah pengujian menjadi biaya per hasil

Tentukan unit kerja dengan kriteria selesai yang jelas: tiket terselesaikan, laporan diterima pemeriksa, patch lulus pengujian, atau jawaban dukungan dinilai benar. Untuk setiap tugas, jumlahkan seluruh biaya run, termasuk kegagalan dan retry, lalu bagi dengan jumlah tugas yang melewati ambang kualitas.

Dalam contoh hipotetis, konfigurasi A berbiaya Rp1.000 per run dan berhasil pada 60 dari 100 tugas. Biaya per keberhasilannya sekitar Rp1.667. Konfigurasi B berbiaya Rp1.300 per run tetapi berhasil 90 kali, sehingga biaya per keberhasilannya sekitar Rp1.444; run yang lebih mahal justru menghasilkan biaya per hasil yang lebih rendah.

Bandingkan konfigurasi dengan dataset, batas waktu, versi alat, dan rubrik penilaian yang sama. Jalankan tugas beberapa kali untuk menangkap variasi. Selain median, laporkan persentil tinggi karena loop panjang yang jarang terjadi dapat menentukan kebutuhan batas anggaran dan kapasitas.

Empat kontrol biaya di dalam workflow agen

Batasi iterasi. Tetapkan maksimum langkah, panggilan alat, retry per alat, dan biaya per tugas. Hentikan run ketika agen mengulang tindakan dengan input serupa, tidak membuat kemajuan, atau telah memenuhi kriteria selesai. Batas dapat dibedakan menurut kelas tugas agar pekerjaan kompleks tidak diperlakukan seperti permintaan sederhana.

Kelola konteks. Jangan mengirim seluruh riwayat dan seluruh hasil alat pada setiap langkah. Simpan artefak besar di luar konteks, teruskan referensi atau ringkasan yang dapat diperiksa, dan ambil hanya potongan yang relevan. Pisahkan instruksi stabil dari data dinamis agar prefix yang sama tidak terus diproses dari awal.

Ukur cache hit. Dokumentasi prompt caching Anthropic menetapkan masa cache standar lima menit dan opsi satu jam. Cache read dihargai 0,1 kali tarif input dasar, sedangkan cache write lima menit 1,25 kali dan write satu jam dua kali tarif dasar; penghematan bergantung pada seberapa sering prefix yang sama benar-benar digunakan kembali sebelum kedaluwarsa.

Rutekan model per langkah. Klasifikasi, ekstraksi, peringkasan, dan pemeriksaan format tidak selalu memerlukan model frontier. Model yang lebih kuat dapat dicadangkan untuk perencanaan sulit, keputusan ambigu, atau eskalasi setelah model kecil gagal. Dokumentasi model router Microsoft Foundry membedakan mode Balanced, Cost, dan Quality, mendukung pemilihan model per langkah agen, serta menyarankan pencatatan model yang benar-benar menangani permintaan.

Checklist observabilitas per tugas

Dashboard biaya harus dapat menelusuri lonjakan hingga langkah penyebabnya. Simpan identitas tugas dan versi konfigurasi tanpa merekam data sensitif yang tidak diperlukan, kemudian kelompokkan metrik berdasarkan jenis tugas, pelanggan, dan rilis:

• token input dan output, token reasoning jika tersedia, serta token yang ditulis dan dibaca dari cache;
• jumlah langkah, durasi, panggilan alat, ukuran hasil alat, retry, dan loop yang dihentikan;
• model pada setiap langkah, alasan routing, eskalasi, dan perubahan model akibat failover;
• biaya total run, batas anggaran, status penghentian, dan biaya per tugas yang lolos evaluasi;
• skor kualitas, jenis kegagalan, intervensi manusia, dan pekerjaan perbaikan setelah agen selesai.

Pisahkan input dari output karena keduanya membutuhkan tindakan berbeda. Input besar mengarah pada pemeriksaan retrieval, konteks, dan cache; output besar mengarah pada batas respons atau format yang lebih ketat. Banyak retry lebih mungkin menunjukkan masalah alat atau kebijakan pemulihan daripada membuktikan bahwa model harus diganti.

Urutan pengujian tanpa mengorbankan kualitas

1. Buat baseline pada kumpulan tugas representatif dan tentukan ambang kualitas sebelum mengoptimalkan biaya.
2. Tambahkan batas iterasi dan deteksi loop, lalu ukur perubahan tingkat keberhasilan serta persentil biaya tinggi.
3. Rapikan konteks dan stabilkan prefix cache; ukur cache hit serta biaya write dan read secara terpisah.
4. Uji routing dengan mengubah satu variabel pada satu waktu, kemudian hitung kembali biaya per keberhasilan, latensi, dan kualitas.
5. Terapkan batas anggaran per langkah, tugas, pengguna, dan periode, disertai jalur eskalasi untuk tugas bernilai tinggi.

Konfigurasi terbaik bukan yang memakai token paling sedikit, melainkan yang memenuhi ambang kualitas dengan biaya per hasil paling rendah dan risiko lonjakan yang dapat diterima. Metrik tersebut mencegah penghematan semu sekaligus menguji asumsi bahwa lebih banyak token berarti agen bekerja lebih baik.