Agent membutuhkan "indikator bahan bakar" dan "rem": Sebuah makalah yang mengungkap "catatan kelabu" Agent

null

Bayangkan skenario ini:

Anda meminta Agen AI membantu memperbaiki bug kode. Ia membuka proyek, membaca 20 file, melakukan perubahan, menjalankan pengujian, tidak lulus, lalu mengubah lagi, menjalankan lagi, tetap tidak lulus… bolak-balik selama lebih dari sepuluh putaran, akhirnya—tetap tidak selesai diperbaiki.

Anda mematikan komputer, merasa lega. Lalu menerima tagihan API.

Angka-angka di atas mungkin membuat Anda terengah-engah—AI Agent yang memperbaiki bug secara mandiri di API resmi luar negeri, satu tugas yang tidak berhasil biasanya menghabiskan lebih dari satu juta Token, biayanya bisa mencapai puluhan hingga ratusan dolar.

Pada April 2026, sebuah makalah penelitian yang diterbitkan bersama oleh Stanford, MIT, University of Michigan dan lain-lain, pertama kali secara sistematis membuka “kotak hitam konsumsi” AI Agent dalam tugas kode—ke mana uang benar-benar mengalir, apakah nilainya sepadan, dan apakah bisa diperkirakan sebelumnya, jawabannya mengejutkan.

Penemuan pertama: Kecepatan biaya penulisan kode oleh Agent adalah 1000 kali lipat dari percakapan AI biasa

Mungkin Anda berpikir: Membiarkan AI membantu menulis kode dan berbicara tentang kode, biayanya harusnya sama saja, kan?

Makalah menunjukkan perbandingan:

Jumlah Token yang dikonsumsi oleh tugas pengkodean Agentic adalah sekitar 1000 kali lipat dari tanya jawab kode dan tugas inferensi kode biasa.

Selisihnya mencapai tiga tingkat kuantitas.

Mengapa bisa begitu? Makalah menunjukkan satu fakta—uang tidak dihabiskan untuk “menulis kode”, melainkan untuk “membaca kode”.

“Membaca” di sini bukan berarti manusia membaca kode, melainkan Agent selama proses kerja harus terus-menerus “memberi makan” konteks proyek secara keseluruhan, riwayat operasi, pesan error, isi file ke model. Semakin banyak putaran dialog, konteks ini menjadi semakin panjang; dan model dihitung berdasarkan jumlah Token—semakin banyak yang Anda beri, semakin banyak pula yang harus Anda bayar.

Sebagai analogi: ini seperti memanggil tukang reparasi yang setiap kali mengencangkan obeng harus Anda bacakan seluruh denah bangunan dari awal—membacakan denah jauh lebih mahal daripada memutar sekrup.

Makalah merangkum fenomena ini dalam satu kalimat: biaya yang dibutuhkan untuk menjalankan Agent didorong oleh pertumbuhan eksponensial Token input, bukan output.

Penemuan kedua: Bug yang sama, dijalankan dua kali, biayanya bisa berbeda dua kali lipat—dan bug yang lebih mahal cenderung lebih tidak stabil

Lebih membuat pusing lagi adalah sifat acak.

Peneliti menjalankan satu Agent yang sama pada satu tugas sebanyak 4 kali, dan hasilnya menunjukkan:

Antara tugas yang berbeda, tugas yang paling mahal menghabiskan sekitar 7 juta Token lebih banyak daripada yang paling murah (Gambar 2a)

Dalam beberapa kali run dengan model dan tugas yang sama, yang paling mahal sekitar 2 kali lipat dari yang paling murah (Gambar 2b)

Dan jika membandingkan antar model untuk tugas yang sama, selisih konsumsi tertinggi dan terendah bisa mencapai 30 kali lipat

Angka terakhir ini sangat penting: ini berarti, perbedaan biaya antara memilih model yang tepat dan yang salah bukan sekadar “lebih mahal sedikit”, melainkan “berbeda satu tingkat kuantitas”.

Lebih menyakitkan lagi—lebih banyak biaya tidak selalu berarti hasil yang lebih baik.

Makalah menemukan kurva “U” terbalik:

Tingkat biaya dan akurasi menunjukkan tren di mana biaya rendah biasanya berkorelasi dengan akurasi rendah (mungkin karena kurang usaha), biaya sedang biasanya paling tinggi, dan biaya tinggi justru menurun dan memasuki “zona jenuh”.

Mengapa bisa begitu? Makalah menganalisis operasi spesifik Agent dan memberikan jawaban—

Dalam operasi biaya tinggi, Agent menghabiskan banyak waktu untuk “kerja berulang”.

Penelitian menunjukkan, dalam operasi biaya tinggi, sekitar 50% dari operasi membaca dan mengubah file adalah duplikat—artinya, Agent berulang-ulang membaca file yang sama, mengubah baris yang sama, seperti orang yang berputar-putar di dalam ruangan, semakin pusing, semakin berputar.

Uang tidak habis untuk menyelesaikan masalah, melainkan untuk “tersesat”.

Penemuan ketiga: Efisiensi “per model” sangat berbeda—GPT-5 paling hemat, ada model yang menghabiskan hingga 1,5 juta Token

Makalah menguji performa 8 model besar terbaru di standar industri SWE-bench Verified (500 isu GitHub nyata). Jika dikonversi ke dolar, model yang efisien dalam penggunaan Token bisa menghabiskan puluhan dolar lebih sedikit per tugas. Dalam aplikasi skala perusahaan—yang menjalankan ratusan tugas per hari—perbedaannya nyata dan berharga.

Penemuan menarik lainnya: efisiensi Token adalah “karakter bawaan” model, bukan tergantung tugas.

Peneliti membandingkan semua tugas yang berhasil diselesaikan oleh semua model (230 tugas) dan semua tugas yang gagal (100 tugas), dan menemukan peringkat relatif model hampir tidak berubah.

Ini menunjukkan: beberapa model secara bawaan “lebih banyak bicara”, tidak terlalu bergantung pada tingkat kesulitan tugas.

Ada penemuan lain yang menggelitik: model tidak memiliki “kesadaran berhenti”.

Dalam menghadapi tugas sulit yang tidak bisa diselesaikan semua model, agen idealnya harus berhenti lebih awal, bukan terus membakar uang. Tapi kenyataannya, model cenderung menghabiskan lebih banyak Token pada tugas gagal—mereka tidak “mengaku kalah”, melainkan terus eksplorasi, coba ulang, baca ulang konteks, seperti mobil tanpa indikator bahan bakar yang terus berjalan sampai mogok.

Penemuan keempat: Apa yang manusia anggap sulit, Agent belum tentu anggap mahal—persepsi kesulitan sangat berbeda

Anda mungkin berpikir: setidaknya saya bisa memperkirakan biaya berdasarkan tingkat kesulitan tugas, kan?

Makalah mengumpulkan penilaian tingkat kesulitan dari 500 tugas oleh para ahli manusia, lalu membandingkannya dengan konsumsi Token aktual oleh Agent—

Hasilnya: hanya berkorelasi lemah.

Dengan bahasa sederhana: tugas yang manusia anggap sangat sulit, mungkin bisa diselesaikan Agent dengan biaya rendah; tugas yang manusia anggap mudah, bisa menghabiskan biaya yang sangat besar.

Ini karena manusia dan AI “melihat” tingkat kesulitan dari sudut berbeda:

Manusia melihat: kompleksitas logika, algoritma, pemahaman bisnis

AI melihat: seberapa besar proyek, berapa banyak file yang harus dibaca, seberapa panjang jalur eksplorasi, apakah akan berulang-ulang mengubah file yang sama

Seorang ahli manusia yang merasa “cukup satu baris” untuk bug, mungkin harus membaca seluruh struktur kode dulu sebelum menemukan baris tersebut—membaca saja sudah menghabiskan banyak Token. Sebaliknya, masalah algoritma yang rumit bagi manusia, mungkin AI tahu solusi standarnya dan bisa menyelesaikan dalam sekejap.

Ini menyebabkan kenyataan pahit: pengembang hampir tidak bisa memperkirakan biaya operasional Agent secara intuitif.

Penemuan kelima: Bahkan model sendiri tidak bisa memperkirakan berapa banyak Token yang akan mereka gunakan

Karena manusia saja tidak bisa memperkirakan, bagaimana jika AI yang memprediksi sendiri?

Peneliti merancang eksperimen canggih: membiarkan Agent sebelum memperbaiki bug, melakukan “inspeksi” terhadap kode, lalu memperkirakan berapa Token yang akan digunakan—tanpa benar-benar memperbaiki.

Hasilnya?

Semua model gagal total.

Prediksi terbaik adalah Claude Sonnet-4.5 dengan korelasi prediksi Token output sebesar 0,39 (skala 0-1). Sebagian besar model hanya berkorelasi antara 0,05 sampai 0,34, Gemini-3-Pro paling rendah, hanya 0,04—hampir seperti tebak-tebakan.

Lebih parah lagi: semua model secara sistematis meremehkan jumlah Token yang akan mereka gunakan. Pada scatter plot di Gambar 11, hampir semua titik data berada di bawah garis prediksi “sempurna”—model merasa tidak akan menghabiskan banyak, padahal kenyataannya lebih banyak. Dan bias underestimation ini semakin parah jika tidak disertai contoh.

Lebih ironis lagi—prediksi sendiri juga memakan biaya.

Prediksi Claude Sonnet-3.7 dan Sonnet-4 bahkan bisa mencapai dua kali biaya tugas itu sendiri. Artinya, membiarkan mereka “menebak harga” malah lebih mahal daripada langsung mengerjakan.

Kesimpulan makalah sangat lugas:

Saat ini, model-model terbaru tidak mampu memprediksi secara akurat jumlah Token yang akan mereka konsumsi. Klik “Jalankan Agen”, sama seperti membuka kotak misteri—baru tahu berapa banyak uang yang terpakai setelah tagihan keluar.

Di balik “kebingungan” ini, tersembunyi masalah industri yang lebih besar

Kalau sudah membaca ini, mungkin Anda bertanya: apa arti semua temuan ini bagi perusahaan?

1. Model berlangganan “berlangganan bulanan” mulai retak

Makalah menunjukkan, alasan ChatGPT Plus dan sejenisnya bisa berjalan adalah karena konsumsi Token dalam percakapan biasa relatif terkendali dan dapat diprediksi. Tapi tugas Agent sepenuhnya membantah asumsi ini—satu tugas bisa saja karena Agent terjebak loop, menghabiskan Token dalam jumlah besar.

Ini berarti, model berlangganan tetap tidak cocok untuk skenario Agent, dan pembayaran berdasarkan penggunaan (Pay-as-you-go) masih menjadi pilihan paling realistis dalam jangka panjang. Tapi masalahnya: penggunaan ini sendiri tidak bisa diprediksi.

2. Efisiensi Token harus menjadi “indikator ketiga” dalam memilih model

Secara tradisional, perusahaan memilih model berdasarkan dua aspek: kemampuan (bisa melakukan tugas) dan kecepatan (biker cepat). Makalah menambahkan aspek ketiga yang sama pentingnya: efisiensi (berapa banyak biaya yang diperlukan).

Model yang sedikit lebih lemah tapi efisien 3 kali lipat secara biaya bisa jadi lebih ekonomis dalam skala besar dibanding model paling kuat tapi paling boros.

3. Agent perlu “indikator bahan bakar” dan “rem”

Makalah menyebutkan satu arah masa depan yang penting—kebijakan penggunaan alat yang “sadar anggaran” (Budget-aware tool-use policies). Secara sederhana, ini seperti memasang “indikator bahan bakar” di Agent: saat konsumsi Token mendekati batas anggaran, paksa dia berhenti eksplorasi yang tidak perlu, bukan terus membakar uang.

Saat ini, hampir semua kerangka kerja Agent utama belum memiliki mekanisme ini.

Masalah “bakar uang” pada Agent bukanlah bug, melainkan tantangan struktural industri—

Makalah ini mengungkapkan, bukan sekadar kekurangan model tertentu, tetapi tantangan struktural dari paradigma Agent itu sendiri—ketika AI bertransformasi dari “tanya jawab” menjadi “perencanaan mandiri, eksekusi multi-langkah, debugging berulang”, ketidakpastian konsumsi Token hampir pasti akan muncul.

Kabar baiknya, ini adalah kali pertama data ini dihitung secara sistematis. Dengan data ini, pengembang bisa lebih bijak memilih model, mengatur anggaran, dan merancang mekanisme berhenti otomatis; produsen model pun memiliki arah baru untuk optimasi—bukan hanya membuat lebih kuat, tetapi juga lebih hemat.

Pada akhirnya, sebelum AI Agent benar-benar masuk ke berbagai industri dan lingkungan produksi, setiap rupiah yang dihabiskan harus jelas penggunaannya—lebih penting daripada menulis baris kode yang tampak rapi dan indah.