# Bagaimana Menetapkan Batas Pengeluaran Keras untuk Tugas Agen Coding? > Batas pengeluaran keras harus ditegakkan sebelum setiap panggilan model atau alat berbayar oleh gateway yang menguasai anggaran tugas. Cadangkan biaya kasus terburuk, rekonsiliasi penggunaan aktual, tolak panggilan yang tidak muat, dan hentikan agen dengan checkpoint yang berguna. # Bagaimana Menetapkan Batas Pengeluaran Keras untuk Tugas Agen Coding? Anggaran tugas keras adalah masalah admission control. Sebelum panggilan model atau alat berbayar dimulai, gateway tepercaya harus membuktikan bahwa biaya maksimum yang diizinkan masih muat di saldo tugas. Peringatan dan laporan setelah proses berguna, tetapi tidak dapat menghentikan kelebihan yang sudah terjadi. Desain harus mencakup token input, output maksimum, percobaan ulang, fallback, subagen, embeddings, pencarian, sandbox, dan setiap alat berbayar lainnya. ## Pisahkan batas keras dari target lunak Gunakan tiga nilai: | Kontrol | Tujuan | Perilaku | |---|---|---| | Target | Biaya yang diharapkan | Peringatkan atau pilih rencana lebih murah | | Batas lunak | Ambang eskalasi | Minta persetujuan atau turunkan kualitas | | Batas keras | Pengeluaran maksimum yang diizinkan | Tolak panggilan berikutnya sebelum mulai | Misalnya, tugas dapat menargetkan $0.60, meminta persetujuan pada $0.90, dan berhenti pada $1.00. Batas keras harus berada di sisi server, bukan hanya di prompt agen. ## Tempatkan semua tindakan berbayar di balik satu gateway Berikan kredensial tugas berumur pendek yang hanya dapat memanggil gateway Anda. Gateway melampirkan `task_id`, membaca anggaran, memperkirakan tindakan berikutnya, lalu mencadangkan dana atau menolak request. Jangan berikan key penyedia yang memungkinkan agen melewati akuntansi. Terapkan aturan yang sama pada pencarian web, sandbox terhosting, eksekusi kode, dan layanan retrieval berbayar. ## Cadangkan sebelum memanggil dan rekonsiliasi sesudahnya Untuk panggilan model, perkirakan batas atas dari token input yang diketahui ditambah output maksimum. Lakukan reservasi atomik, kirim request, lalu ganti reservasi dengan penggunaan aktual. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` Reservasi atomik mencegah dua subagen paralel membelanjakan saldo tersisa yang sama. ## Tetapkan harga dengan rate card berversi Simpan harga yang digunakan untuk setiap estimasi bersama peristiwa. Harga model dan aturan penagihan dapat berubah, sehingga laporan tidak boleh menghitung ulang penggunaan lama dengan harga hari ini. Saat penyedia mengembalikan biaya resmi, simpan estimasi dan biaya akhir. Jika hanya token yang diberikan, gunakan versi rate card yang dipilih sebelum panggilan. Tambahkan cadangan konservatif untuk biaya alat yang tidak diketahui atau tolak panggilan yang biaya maksimumnya tidak dapat dibatasi. ## Amankan streaming Cadangkan seluruh biaya respons yang diizinkan sebelum membuka stream. Hitung penggunaan yang diterima jika tersedia, tetapi jangan berasumsi bahwa menutup koneksi client langsung menghentikan penagihan. Pembatalan adalah optimasi, bukan batas penegakan. Tetapkan batas output per panggilan dan wall-clock timeout. Batas tugas keras mencakup total semua stream, retry, dan fallback. ## Sertakan percobaan ulang dan subagen Setiap percobaan mendebit ledger tugas induk yang sama. Kebijakan retry yang diam-diam membuka anggaran baru akan mengalahkan batas. Gunakan anggaran hierarkis saat mendelegasikan: | Ledger | Batas | Aturan | |---|---:|---| | Tugas induk | $1.00 | Batas mutlak | | Subagen implementasi | $0.55 | Tidak boleh melebihi saldo induk | | Subagen analisis tes | $0.25 | Mengembalikan reservasi yang tidak dipakai | | Review akhir | $0.20 | Berjalan hanya jika dana tersisa | Batas child adalah alokasi, bukan uang tambahan. ## Berhenti dengan checkpoint yang berguna Ketika tindakan berikutnya tidak muat, kembalikan error bertipe yang dipahami orkestrator. Agen tidak boleh terus mengulang panggilan yang ditolak. Minta agen membuat checkpoint tanpa biaya dari konteks yang ada, berisi: * perubahan selesai dan hasil tes; * pekerjaan tersisa dan tindakan yang diblokir; * status repositori saat ini; * estimasi anggaran tambahan; * resume token atau ID tugas. Ini mengubah penghentian anggaran menjadi handoff terkendali, bukan proses parsial yang rusak. ## Gunakan kontrol penyedia sebagai pengaman Batas akun penyedia dan gateway dapat mengurangi dampak, tetapi jarang menjadi kontrol per tugas yang presisi. Batas itu dapat menggabungkan banyak repositori, diperbarui secara asinkron, atau tidak mencakup biaya alat. Dengan gateway multimodel seperti Atlas Cloud, simpan ledger tugas resmi di lapisan orkestrasi dan catat ID penggunaan gateway untuk rekonsiliasi. Batas keras tetap terjaga ketika tugas berganti model. ## Uji batas seperti kontrol keuangan Uji panggilan paralel, stream panjang, timeout penyedia, field penggunaan hilang, retry, fallback model, dan kegagalan ledger. Tolak secara default jika layanan anggaran tidak tersedia. Verifikasi bahwa biaya committed ditambah reservasi terbuka tidak pernah melebihi batas keras. ## Kesimpulan Batas pengeluaran keras yang nyata ditegakkan sebelum uang dibelanjakan, dengan reservasi atomik dan satu ledger untuk semua tindakan berbayar. Jika sistem hanya memberi peringatan setelah penggunaan tiba, itu adalah monitoring, bukan batas keras. ## FAQ ### Apakah max_tokens merupakan batas dolar yang keras? Tidak. Itu membatasi panjang satu respons, bukan total biaya tugas, token input, percobaan ulang, pergantian model, atau alat berbayar. Batas uang membutuhkan ledger anggaran untuk setiap tindakan berbayar. ### Di mana anggaran agen coding harus ditegakkan? Tegakkan di gateway sisi server atau lapisan orkestrasi yang wajib dilalui semua panggilan model dan alat berbayar. Penghitung sisi client dapat dilewati atau mengalami race saat konkurensi. ### Bagaimana menganggarkan respons streaming? Cadangkan biaya output maksimum yang diizinkan sebelum membuka stream, lalu rekonsiliasi dengan penggunaan yang dilaporkan ketika selesai. Batalkan di penyedia jika didukung, tetapi jangan hanya mengandalkan pembatalan. ### Haruskah percobaan ulang memakai anggaran tugas semula? Ya. Percobaan ulang, fallback, subagen, dan panggilan evaluasi harus mendebit ledger tugas yang sama kecuali pengguna secara eksplisit menyetujui anggaran terpisah. ### Apa yang terjadi ketika sisa anggaran terlalu kecil? Tolak tindakan berbayar berikutnya dan minta agen membuat checkpoint dari konteks yang tersedia, berisi pekerjaan selesai, hal yang belum terselesaikan, dan anggaran tambahan yang dibutuhkan. ### Bisakah batas akun penyedia menggantikan batas per tugas? Biasanya tidak. Batas akun melindungi seluruh akun dan dapat diperbarui terlambat. Gateway per tugas memberi isolasi langsung, sedangkan batas akun tetap menjadi pengaman tambahan.