Tool server adalah faktur terpisah
Diperbarui September 1, 2026 · pertama terbit September 1, 2026
Sebagian besar model biaya LLM hanya punya satu meter: token masuk, token keluar, harga per juta. Model itu benar ketika satu-satunya hal yang dilakukan sebuah permintaan adalah menghasilkan teks. Model itu berhenti benar begitu tool sisi server datang.
Pencarian web, web fetch, dan eksekusi kode berjalan di infrastruktur penyedia, dan beberapa di antaranya membawa biaya per penggunaan sendiri di atas token yang mereka hasilkan. Satu giliran agen karenanya bisa menagih Anda dua kali: sekali untuk pencarian yang dijalankan, dan lagi untuk token yang ditambahkan hasil-hasil itu ke konteks.
Bagian yang berlipat ganda
Biaya kedua adalah yang sering terlewat. Setiap hasil tool ditambahkan ke percakapan, dan setiap giliran berikutnya mengirim ulang seluruhnya sebagai input. Sepuluh pencarian di awal run agen yang panjang bukan sepuluh biaya — melainkan sepuluh biaya ditambah payload hasilnya yang dibaca ulang di setiap giliran berikutnya.
Itulah sebabnya biaya agen terasa tidak linear padahal hitungan token mengatakan seharusnya linear. Biaya per penggunaan adalah bagian yang terlihat; pertumbuhan konteks yang ditimbulkannya adalah bagian yang lebih besar, dan ia masuk ke baris token input tanpa label apa pun yang menandainya sebagai akibat tool.
Atribusikan atau Anda tidak bisa mengelolanya
Catat pemanggilan tool per permintaan bersama objek penggunaan: tool apa, berapa kali dipanggil, dan ukuran token dari setiap hasil yang ditambahkan. Kolom terakhir itulah yang membuat pertumbuhan berlipat terlihat, dan itu yang biasanya tidak dicatat secara default.
Lalu hitung biaya per run agen, bukan biaya per panggilan API. Run adalah apa yang benar-benar dipicu pengguna; panggilan API hanyalah salah satu dari dua puluh hal yang dilakukan run itu. Angka anggaran atau unit-economics yang dilekatkan pada panggilan, bukan run, akan keliru ke arah yang membuat Anda terlihat lebih baik.
Tiga kontrol yang benar-benar berhasil
Batasi jumlah pemanggilan tool per run. Batas keras pada pencarian atau fetch per permintaan pengguna membatasi kedua biaya sekaligus. Sebagian besar beban kerja yang menyentuh batas sepuluh sebenarnya sedang melakukan loop, bukan riset.
Potong apa yang masuk ke konteks. Anda jarang butuh seluruh halaman yang di-fetch. Meringkas atau memangkas hasil sebelum ditambahkan mengurangi setiap giliran berikutnya, bukan hanya giliran saat ini.
Cache prefiks yang stabil. Jika prompt sistem dan definisi tool tetap sama selama satu run — dan biasanya memang begitu — prompt caching menghapus biaya berulang terbesar yang ditimbulkan tool.
Periksa rate card penyedia Anda saat ini sebelum memodelkan semua ini: tool mana yang menagih per penggunaan, dan dengan tarif berapa, berbeda tiap tool dan berubah dari waktu ke waktu. Poin strukturalnya tetap berlaku: meter token bukan lagi keseluruhan tagihan.
Terkait
Terkait
Ingin menerapkannya pada stack Anda? Bawa tagihan penyedia, log gateway, dan alur kerja utama; kami akan memetakan pendorong biaya dan jalur penghematan. Pesan audit gratis →