ThinkingBox Rilis: Cara Ngecek Reliabilitas Agen AI di Database

Apa itu ThinkingBox dan kenapa reliabilitas agen AI database penting?

ThinkingBox itu sandbox buat ngejalanin agen, sementara ThinkingBox-Bench adalah dataset 507 workflow bisnis yang statusnya berubah-ubah (stateful)—kayak retail, asuransi mobil, travel, neobank, sampai consulting. Tiap tugas dijalanin 20 kali berturut-turut dari kondisi backend yang sama-sama bersih, lalu dicek: apa yang benar-benar berubah di database, bukan cuma apa yang dibilang agennya.

Kenapa ini penting? Karena menurut temuan mereka, trajectory (urutan tool call dan jawaban) itu cuma klaim. Database adalah bukti. Dalam satu ablation yang ngecek 121.680 trial valid dari 12 model LLM, ada 79.853 attempt yang gagal lolos cek executable. Dari yang gagal itu, 67,24% tetap kelihatan "bersih"—selesai tanpa error, manggil tool yang ngubah state, dan nggak ada error di tool terakhir. Tapi pas dicek state-nya: 77,61% punya nilai field yang salah, 43,30% bikin efek tambahan yang nggak diminta, dan 25,36% malah kelewat satu efek yang wajib ada.

Artinya, kalau cuma ngandelin apakah agen "kelihatan selesai dengan benar", kamu bisa ketipu lebih dari separuh waktu. Buat kamu yang lagi bikin atau evaluasi agent ai buat kerjaan nyata—customer service, billing, inventory—ini jadi alasan kenapa cek harus sampai ke level data, bukan cuma transkrip percakapan.

Pass@1, Pass@20, Observed 20/20: ngukur konsistensi, bukan cuma skor sekali jalan

ThinkingBox nggak cuma ngasih satu angka. Ada tiga metrik yang dipakai:

Angka pass@1 yang paling sering dipajang di leaderboard itu kelihatan kayak ranking kemampuan biasa. Berikut hasil pass@1 per domain dari paper-nya:

Claude Opus 5.5 memimpin dengan 67,16%, cuma unggul tipis dari Claude Opus 5. Kimi-K3 jadi model open-weight paling kuat, bahkan ngalahin semua model proprietary di domain retail (82,24%). Tapi lihat juga gimana Claude Opus 4.6 jago banget di retail (68,62%) tapi ambruk total di asuransi mobil (8,30%)—domain memang bikin hasil bisa beda jauh.

Yang lebih penting: begitu tugas yang sama diulang 20 kali, berapa persen dari skor pass@1 itu yang masih bertahan?

Jomplang banget kan? Model yang skornya kelihatan bagus sekali coba, ternyata banyak yang ambyar kalau diulang berkali-kali.

Siapa model paling konsisten? Kimi-K3 vs Claude Opus

Di sini letak temuan paling menarik. Kimi-K3 punya cakupan paling luas dari semua model yang diuji: dia berhasil nyelesain 93,89% dari 507 tugas minimal sekali (476 tugas), dan cuma 31 tugas yang bener-bener nggak bisa dia pecahin sama sekali—paling rendah di antara semua model.

Tapi Kimi-K3 juga salah satu model paling nggak konsisten. Cuma 68 dari 507 tugas (13,41%) yang dia selesaikan benar di SEMUA 20 percobaan.

Claude Opus 5 kebalikannya. Dia cuma berhasil minimal sekali di 79,09% tugas (106 tugas sama sekali nggak bisa dia pecahin), tapi dia nyelesain 47,53% dari seluruh benchmark dengan sempurna di semua 20 attempt.

Menariknya lagi, Claude Opus 5.5 yang lebih baru punya skor every-attempt average lebih tinggi dari Claude Opus 5 (67,16% vs 66,50%) dan lebih banyak nyelesain tugas minimal sekali. Tapi jumlah tugas yang lolos 20/20 sama persis: 241 tugas. Artinya, setengah poin kenaikan akurasi di headline nggak nambah dependability sama sekali.

Kesimpulannya: kalau kamu mau pilih model buat kerjaan yang nyentuh data asli—bukan sekadar demo—angka pass@20 (bisa nggak sih dia pernah berhasil) itu kolom yang salah buat dilihat. Yang lebih relevan adalah observed 20/20.

Berapa biaya agen yang benar-benar bisa diandalkan?

Skor doang nggak cukup—biayanya juga perlu dihitung. ThinkingBox ngitung dua jenis biaya pakai harga list OpenRouter (snapshot 20 September 2026): biaya per keberhasilan tugas, dan biaya per tugas yang dependable (lolos 20/20).

Untuk biaya per sukses tunggal, GPT-5.6 Sol paling murah di $0,127, GPT-5.4 di $0,131, dan Claude Opus 5.5 di $0,276. Sebagai pembanding, Claude Opus 5 malah lebih mahal di $0,475 per sukses—padahal akurasinya (66,50%) lebih rendah dari Opus 5.5 (67,16%). Jadi Opus 5 kalah di dua sisi sekaligus.

Tapi biaya per sukses tunggal itu nggak ngasih reward buat model yang benar SETIAP kali. Makanya ada hitungan cost per dependable task—biaya kampanye 20 run dibagi jumlah tugas yang lolos 20/20:

Kelihatan jelas: model paling murah per sukses tunggal (GPT-5.6 Sol) ternyata nggak jadi yang paling murah per tugas yang dependable ($9,76). Sementara Claude Opus 5 yang sama-sama lolos 241 tugas kayak Opus 5.5, biayanya hampir dua kali lipat ($13,30 vs $7,80). Jadi cara tercepat dapet jawaban benar itu berbeda dari cara termurah dapet jawaban yang bisa diandalkan.

Kenapa agen AI sering gagal? Bukan soal nalar, tapi soal tool handling

Bagian paling actionable dari riset ini: ThinkingBox ngasih label diagnostik ke setiap kegagalan, dan hasilnya hampir 4 dari 5 kegagalan itu soal tool handling, bukan soal reasoning modelnya.

Pola yang kelihatan: agen biasanya udah sampai jauh dalam ngerjain workflow, lalu gagal recover dari error tool, precondition yang gagal, atau lookup yang kosong. Itu masalah retry dan error-recovery, bukan masalah model-nya nggak pintar.

Domain juga ngaruh ke tingkat kesulitan—rata-rata pass@1 di retail itu 59,52%, sementara di asuransi mobil cuma 33,83%. Microsoft nyaranin beberapa langkah praktis: perlakukan rate 20/20 sebagai input desain (bukan verdict akhir), klasifikasi error tool biar retry diarahkan ke yang memang bisa di-recover, perkecil jumlah tool yang dikasih ke agen sesuai kebutuhan workflow, dan wajibkan approval manusia buat perubahan yang susah di-reverse.

Kalau kamu udah pernah baca soal AutoSynthData dari ServiceNow yang bikin agen belajar dari kegagalannya sendiri, pendekatan ThinkingBox ini melengkapi—satu sisi ngajarin agen biar nggak gagal, sisi lain ngasih cara ngukur gagalnya seberapa sering dan di mana.

Gimana cara kerjanya di balik layar?

Tiap tugas di ThinkingBox-Bench punya starting backend state, tujuan user, daftar tool MCP yang tersedia, kebijakan domain, dan cek executable atas state terakhir. Ada simulated user yang nyimpen konteks privat (nomor booking, preferensi, tanggal lahir) dan cuma ngasihnya kalau ditanya.

Setiap attempt dapet sesi MCP yang benar-benar terisolasi dengan state yang baru di-reset—dua attempt dari tugas yang sama nggak pernah berbagi baris database atau cache tool, yang bikin perbandingan 20 kali itu valid secara adil. Di akhir, side-effect extractor ngecek apa yang berubah, lalu judge deterministik bandingin itu sama required end state—nerima trajectory apapun yang hasil akhirnya benar, dan nolak kalau ada efek yang salah, kurang, atau kelebihan. Buat requirement yang nggak punya nilai database bersih (misal "apakah agen ngasih tahu ini nggak dijamin?"), ada rubrik binary sempit yang nangani. Dari 507 tugas, 477 dinilai murni dari state, sisanya 30 nambah rubrik respons.

Cara nyobain ThinkingBox dan OpenEnv sendiri

ThinkingBox sekarang udah ada di Hugging Face, lengkap sama harness dan dataset-nya, dan jalan lewat interface OpenEnv. Kalau kamu developer yang lagi bangun atau evaluasi agen sendiri, ini langkah-langkahnya:

1. Install komponen utama. Clone repo OpenEnv dan sync environment thinkingbox pakai uv, lalu clone thinkingbox-data di release yang di-pin (thinkingbox-bench-v1.0), dan install CLI tb dari microsoft/thinkingbox.
2. Nyalain Typesense. Jalanin container Typesense 30.1 dan tunggu health check-nya sukses.
3. Nyalain MCP server. Jalanin Session Proxy dan MCP server pakai tb mcp-start, arahkan ke file servers.yaml dari thinkingbox-data.
4. Nyalain OpenEnv server. Jalanin server OpenEnv dengan config YAML yang nunjuk ke tiga model (agen, simulated user, judge)—bisa pakai satu endpoint buat ketiganya biar simpel. Lihat config guide buat detailnya.
5. Cek readiness. Pastikan endpoint /ready udah lolos sebelum lanjut, karena dia ngecek data, konfigurasi, dan Session Proxy.
6. Score satu episode. Pakai thinkingbox-eval buat ngejalanin satu test case (misalnya test_case_ST002_001) dan lihat hasilnya di results.jsonl.

Semua run di-gate pakai commit framework yang di-pin, data release yang di-pin, dan bundle hash, jadi hasilnya bisa diverifikasi, bukan cuma klaim sepihak. Kode ThinkingBox lisensinya MIT, data benchmark-nya CDLA-Permissive-2.0, dan environment OpenEnv-nya BSD-3-Clause.

Kamu adalah agen customer service. Sebelum menutup tiket sebagai "resolved", cek dulu:1. Apakah semua status terkait (pengiriman, pembayaran, refund) di sistem backend sudah sesuai dengan kondisi yang seharusnya?2. Apakah pertanyaan asli dari pelanggan sudah benar-benar terjawab, bukan cuma ditutup administratif?Kalau salah satu belum terpenuhi, JANGAN tutup tiket. Jelaskan ke pelanggan apa yang masih pending dan langkah selanjutnya.

Dampaknya buat developer dan bisnis di Indonesia

Buat tim developer di Indonesia yang mulai bangun agen AI—baik buat customer service, finance ops, atau internal tool—riset ini ngasih pelajaran penting: jangan cuma percaya respons teks "tugas selesai". Kalau agen kamu nyentuh data pelanggan, transaksi, atau status pembayaran, itu juga menyangkut tanggung jawab data di bawah UU PDP. Kesalahan state yang nggak ketahuan bisa berarti data pelanggan ke-update salah, bukan cuma "typo" di jawaban chatbot.

Buat yang mau nyobain model-model yang disebut di benchmark ini, beberapa di antaranya tersedia di Classai Router dengan satu API key yang sama—tinggal ganti nama model di kode kamu. Misalnya Claude Opus 5.5 (Rp7.700/Rp38.400 per 1 juta token input/output), Claude Opus 5 (Rp160/Rp800), Kimi K3 (Rp4.000/Rp5.000), GPT-6 Astra (Rp2.240/Rp11.200), GPT-5.6 Sol (Rp2.240/Rp11.200), DeepSeek V4 Pro (Rp2.000/Rp4.000), dan GLM 5.1 (Rp1.800/Rp4.000). Cocok dipakai buat bikin eksperimen kecil: jalanin tugas yang sama berkali-kali dari dua model berbeda, lalu bandingin mana yang konsisten—bukan cuma siapa yang kelihatan pintar di percobaan pertama.

Kalau kamu baru mulai belajar soal API dan cara kerja agen AI, baca dulu panduan dasar API AI buat pemula biar nggak bingung sama istilah MCP, tool call, dan endpoint yang disebut di artikel ini. Buat yang mau serius upgrade skill bangun agen AI untuk kerjaan, kelas AI untuk Developer di Classai juga bisa jadi langkah lanjutan yang pas.

Oh ya, penulis artikel ThinkingBox ini, Tuhin Kundu dari Microsoft, sebelumnya juga pernah nulis soal topik developer lain yang nggak kalah relevan buat tim yang kerja bareng Hugging Face.

Kalau ngebangun agent ai yang reliable itu ngena ke kamu, dua tulisan ini (ThinkingBox dan Foundry Managed Compute) sama-sama datang dari tim yang sering gali masalah praktis seputar deployment model AI di skala enterprise.