GPT-6 Astra vs Claude Fable 5.1: Apa yang Sebenarnya Dikatakan Benchmark

Angka yang paling sering dibagikan dari perbandingan ini terlihat tegas: 64,6% berbanding 52,6% pada Terminal-Bench Science 0.1, lalu 95,9% berbanding 84,3% pada BenchCAD. Namun angka-angka itu bukan putusan umum bahwa satu model “lebih baik” daripada yang lain. Keduanya adalah hasil pada tugas, harness, anggaran, alat, dan aturan penilaian tertentu. Mengubahnya menjadi klaim tentang semua pekerjaan AI justru menghapus informasi yang paling penting.

OpenAI melaporkan hasil GPT-6 Astra dalam tabel peluncurannya. Anthropic melaporkan hasil Claude Fable 5.1 dalam tabel dan catatan metodologinya sendiri. ARC Prize, sebagai organisasi independen, memberi konteks lain melalui skor ARC-AGI. Ketiga sumber tersebut berguna, tetapi tidak dapat dijahit menjadi satu papan peringkat tanpa memeriksa apakah tugas dan protokolnya sama. Artikel ini membaca angka yang tersedia sebagaimana adanya: sinyal untuk memilih evaluasi dan uji kerja, bukan pengganti keduanya.

Dua angka OpenAI yang paling langsung membandingkan Astra dan Fable 5.1 berasal dari baris yang sama pada halaman peluncuran Astra. Pada Terminal-Bench Science 0.1, Astra memperoleh 64,6% sementara Fable 5.1 tercatat 52,6%. Pada BenchCAD dengan alat, Astra mencapai skor geometric-overlap 95,9%, sedangkan Fable 5.1 tercatat 84,3%. Perbedaan aritmetiknya masing-masing 12,0 dan 11,6 poin persentase. Itu adalah deskripsi yang lebih tepat daripada mengatakan Astra menang dengan margin tertentu pada “AI secara umum”.

Halaman peluncuran OpenAI menjelaskan Terminal-Bench Science 0.1 sebagai evaluasi workflow riset ilmiah yang memakai kode dan alat terminal, termasuk analisis data, simulasi, serta pemodelan atau fitting model. BenchCAD menguji rekonstruksi objek 3D dari render multi-view melalui pembuatan kode CAD. Dua-duanya penting, tetapi jelas tidak mengukur hal yang sama. Yang satu menguji agen menyelesaikan kerja ilmiah lewat lingkungan terminal; yang lain menilai keluaran geometri dari program CAD.

Karena itu, hasil Terminal-Bench Science tidak otomatis menjawab siapa yang lebih baik untuk menggambar presentasi, menulis ringkasan, menangani basis pengetahuan internal, atau mengelola antarmuka desktop. Sebaliknya, skor BenchCAD hampir sempurna tidak membuktikan ketahanan pada tugas penelitian berjenjang. Benchmark adalah instrumen pengukuran dengan cakupan tertentu, bukan tes darah untuk kecerdasan umum.

Ada pula alasan praktis untuk berhati-hati pada tabel vendor. Tabel OpenAI memuat angka Fable 5.1 pada sebagian benchmark, bukan sebuah paket perbandingan yang identik di seluruh domain. Misalnya, halaman yang sama mencantumkan Astra 57,9% dan Fable 5.1 55,8% pada Terminal-Bench 4.0. Tetapi untuk beberapa baris lain, angka kompetitor tidak tersedia. Ketiadaan angka tidak bisa diartikan sebagai keunggulan, kekalahan, atau bukti bahwa tugas tersebut tidak relevan.

Perbandingan yang layak dimulai dari pertanyaan yang sempit: tugas apa yang ingin diselesaikan, bagaimana keberhasilan dinilai, dan konfigurasi apa yang digunakan? Setelah itu, skor dari benchmark yang paling dekat dengan pekerjaan tersebut menjadi petunjuk awal. Memulai dari nama model lalu mencari angka pembenarnya adalah urutan yang terbalik.

Benchmark dirancang untuk membuat kemampuan yang sulit diukur menjadi tugas yang dapat diulang. Ia menetapkan input, lingkungan, batas waktu, alat, dan sebuah cara menghitung sukses atau gagal. Kelebihan pendekatan itu adalah komparabilitas. Kekurangannya juga sama: hasil hanya berlaku sejauh kondisi evaluasinya menyerupai kondisi penggunaan.

Dalam Terminal-Bench Science 0.1, keberhasilan berkaitan dengan rangkaian workflow ilmiah di terminal. Agen perlu membaca keadaan kerja, memilih perintah, menjalankan komputasi, mungkin memperbaiki kesalahan, dan menyerahkan hasil yang dapat diperiksa. Angka 64,6% dan 52,6% memberi sinyal bahwa pada setup yang dilaporkan OpenAI, Astra menyelesaikan lebih banyak tugas daripada Fable 5.1. Mereka tidak memberi tahu berapa kali model akan memahami nomenklatur proyek Anda, menemukan file yang tidak disebutkan, atau memilih antara memperbaiki kode dan meminta klarifikasi.

BenchCAD juga memiliki batas interpretasi sendiri. Jika metriknya geometric overlap, program CAD dinilai dari seberapa dekat bentuk yang dihasilkan dengan target. Nilai tinggi merupakan bukti kuat untuk jenis rekonstruksi itu. Namun perusahaan dapat lebih peduli pada parameter yang mudah disunting, kepatuhan terhadap standar manufaktur, dokumentasi desain, atau kemampuan menjelaskan asumsi. Semua itu dapat penting tanpa menjadi bagian dari angka geometric-overlap yang dikutip.

Peta tetap berguna. Jika tim membangun agen untuk mengolah data eksperimen melalui terminal, Terminal-Bench Science lebih relevan daripada tes pengetahuan tanpa alat. Jika tim membuat sistem dari render menuju CAD, BenchCAD lebih dekat dengan penggunaan yang dimaksud. Yang keliru adalah memperlakukan peta sebagai salinan lengkap wilayah. Peta jalan tidak menampilkan setiap penutupan jalan; benchmark juga tidak menangkap setiap konteks, data, integrasi, dan kebijakan produksi.

Model yang unggul pada sebuah peta bisa menghadapi hambatan yang tidak muncul pada peta lain. Perbedaan itu bukan anomali yang harus disembunyikan. Justru itulah informasi untuk memilih evaluasi yang tepat. Penilaian yang baik tidak bertanya “siapa juaranya?” terlebih dahulu. Penilaian yang baik bertanya “di tugas kami, jenis kegagalan mana yang mahal, dan apakah benchmark ini dapat melihatnya?”

Kata “benchmark” sering terdengar seperti satu angka yang berdiri sendiri. Dalam praktik evaluasi agen, skor lahir dari sebuah sistem: model, prompt atau instruksi, harness yang mengendalikan langkah agen, daftar alat, batas iterasi, batas waktu, kebijakan retry, dan pemeriksa hasil. Mengganti salah satu unsur dapat mengubah peluang agen mencapai jawaban yang dinilai benar.

Harness adalah lapisan pelaksana di antara model dan tugas. Ia dapat menentukan cara model melihat file, format panggilan alat, kapan konteks dipotong, bagaimana kesalahan terminal ditampilkan, serta apakah agen dapat mencoba lagi. Pada tugas multi-langkah, detail itu bukan kosmetik. Jika satu agen mendapat akses browser, interpreter, atau alat pencarian yang berbeda, perbandingan hasilnya bukan lagi pengukuran kemampuan model semata.

Protokol juga menentukan apa yang dihitung sebagai sukses. OSWorld 2.0, misalnya, dilaporkan Anthropic dalam dua cara: 77,9% untuk skor parsial dan 41,7% untuk skor strict. Skor parsial memberi kredit untuk kemajuan atau bagian pekerjaan yang selesai sesuai aturan benchmark; skor strict menghitung keberhasilan penuh dengan kriteria yang lebih keras. Kedua angka tersebut tidak bertentangan. Mereka menjawab pertanyaan berbeda tentang kinerja pada task release yang sama.

Pengumuman Anthropic juga menyatakan bahwa angka OSWorld 2.0 tersebut menggunakan rilis tugas benchmark pada Agustus 2026. Anthropic secara eksplisit memperingatkan bahwa file tugas berbeda dari rilis sebelumnya, sehingga angka itu tidak dapat dibandingkan langsung dengan hasil OSWorld 2.0 yang telah diterbitkan lebih dulu. Versi benchmark bukan catatan kaki kecil. Ia menentukan kumpulan masalah yang harus dihadapi model.

Terminal-Bench juga memiliki versi. Terminal-Bench Science 0.1 dan Terminal-Bench 4.0 bukan nama alternatif untuk evaluasi yang sama. Yang pertama berfokus pada workflow riset ilmiah; yang kedua mencakup tugas terminal kompleks seperti rekayasa perangkat lunak, konfigurasi sistem, dan analisis data. Membandingkan 64,6% pada Science dengan 55,8% pada 4.0 tanpa menyebut nama lengkap benchmark akan membuat pembaca mengira angka itu berada pada skala tugas yang identik.

Ada juga perbedaan antara hasil yang diterbitkan vendor dan leaderboard publik. Anthropic mencatat bahwa leaderboard publik Terminal-Bench Science menggunakan tiga trial per tugas dan Claude Code harness. Catatan ini berguna bukan untuk mendiskreditkan salah satu angka, melainkan untuk mengingatkan bahwa konfigurasi evaluasi harus ikut dibaca. “Skor model” adalah singkatan praktis; bentuk lengkapnya adalah skor model dalam protokol tertentu.

Jika ukuran kemenangan adalah Terminal-Bench Science 0.1 pada tabel OpenAI, Astra berada di atas Fable 5.1: 64,6% versus 52,6%. Jika ukuran kemenangan adalah BenchCAD dengan alat pada tabel itu, Astra juga lebih tinggi: 95,9% versus 84,3%. Jika ukuran yang dibaca adalah Humanitiy’s Last Exam dengan alat dari tabel OpenAI, Fable 5.1 tercatat 65,0% dan Astra 57,2%. Perbedaan arah ini cukup untuk menolak narasi satu pemenang menyeluruh.

Nama benchmark yang benar adalah Humanity’s Last Exam, sering disingkat HLE. Anthropic melaporkan Fable 5.1 mendapat 60,9% pada HLE tanpa alat dan 65,0% dengan alat. Kenaikan antara kedua konfigurasi itu menunjukkan sesuatu yang sederhana tetapi penting: akses alat dapat mengubah hasil. Ia tidak otomatis berarti model “lebih cerdas” setelah alat dinyalakan; ia berarti sistem model-plus-alat menyelesaikan lebih banyak item menurut protokol HLE tersebut.

Fable 5.1 juga melaporkan 55,8% pada Terminal-Bench 4.0 dalam pengumuman Anthropic. Halaman OpenAI menampilkan angka yang sama untuk Fable 5.1 di samping 57,9% untuk Astra. Selisih 2,1 poin ini jauh lebih kecil daripada selisih pada Terminal-Bench Science yang dikutip di awal. Pembaca yang hanya melihat satu kartu sorotan akan kehilangan bentuk keseluruhan: keunggulan yang dilaporkan bervariasi menurut tugas.

Istilah “menang” juga menyamarkan trade-off. Satu tim mungkin mengutamakan tingkat selesai penuh pada desktop. Tim lain membutuhkan output CAD yang terukur. Tim riset mungkin memilih berdasarkan kemampuan menjalankan workflow ilmiah, sedangkan tim produk mengevaluasi ketahanan terhadap instruksi yang ambigu, biaya per tugas selesai, dan audit trail. Tidak ada bobot universal untuk semua tujuan tersebut.

Maka kesimpulan yang tepat bukan bahwa angka benchmark tidak penting. Angka itu sangat penting ketika tugasnya sesuai. Kesimpulan yang tepat adalah bahwa klaim harus menyebut batasnya. Astra memimpin angka yang dilaporkan OpenAI pada dua benchmark spesifik tadi. Fable 5.1 memiliki angka kuat pada konfigurasi dan evaluasi lain, termasuk HLE dengan alat dalam tabel OpenAI. Tidak ada dasar dari kumpulan angka ini untuk menyatakan salah satu model sebagai pemenang mutlak.

Model agen tidak selalu mengalokasikan jumlah kerja internal yang sama untuk setiap permintaan. Pengaturan effort dapat memengaruhi berapa banyak iterasi, pemeriksaan, atau langkah penalaran yang digunakan sebelum menghasilkan tindakan atau jawaban. Dalam pekerjaan berbasis alat, effort juga dapat berkaitan dengan seberapa sering agen menjalankan kode, memeriksa hasil, lalu memperbaiki rencananya.

Halaman OpenAI menggambarkan effort yang lebih tinggi sebagai lebih banyak iterasi pada build baru, lebih banyak verifikasi lewat pengujian browser, dan kecenderungan lebih besar untuk mengeksekusi kode daripada sekadar menerapkan patch. Ini bukan jaminan bahwa effort tinggi selalu lebih baik. Ia bisa meningkatkan peluang menemukan kesalahan pada tugas tertentu, tetapi juga menambah waktu dan konsumsi token. Di sisi lain, effort rendah dapat cukup untuk tugas yang sederhana atau terstruktur.

Itulah sebabnya benchmark harus dibaca bersama anggaran evaluasinya. Batas token, jumlah langkah, durasi eksekusi, jumlah trial, dan harga alat semuanya dapat mengubah strategi yang layak ditempuh agen. Agen yang diizinkan memeriksa jawabannya beberapa kali tidak berada dalam situasi yang sama dengan agen yang harus berhenti setelah satu percobaan. Begitu pula model yang memiliki akses alat pencarian tidak sedang diuji pada kondisi yang sama dengan model tanpa alat.

HLE menyediakan contoh yang mudah dibaca. Anthropic melaporkan 60,9% untuk Fable 5.1 tanpa alat dan 65,0% dengan alat. Perbedaan 4,1 poin itu bukan gangguan dalam data. Ia adalah hasil dari protokol yang berbeda, dan mengingatkan bahwa pembeli perlu menentukan konfigurasi yang akan dipakai di produksi sebelum menganggap angka benchmark relevan.

Anggaran biaya menambah lapisan lain. Sebuah model dapat memakai lebih banyak keluaran token, panggilan alat, atau iterasi untuk mengejar skor tinggi. Yang penting bagi operasi bukan hanya harga per juta token, melainkan biaya untuk menyelesaikan tugas dengan kualitas yang diterima. Nilai ini bergantung pada panjang konteks, cache, tingkat kegagalan, jumlah intervensi manusia, dan apakah keluaran dapat langsung digunakan atau harus diperbaiki.

Karena angka publik tidak menggantikan evaluasi internal, tim sebaiknya menetapkan anggaran yang realistis dalam tes sendiri. Gunakan dokumen, repositori, konektor, dan aturan akses yang mendekati lingkungan produksi, tetapi jangan masukkan data rahasia ke layanan tanpa dasar kebijakan yang sesuai. Ukur kualitas, waktu, biaya, dan jenis kesalahan dalam setup yang sama untuk kedua kandidat. Baru hasil itu dapat membantu keputusan operasional.

Dokumentasi model Claude Fable 5.1 mencantumkan context window 1 juta token dan output maksimum 128 ribu token. Harganya tercantum US$10 per juta token input dan US$50 per juta token output. Untuk cache read, tarifnya US$0,25 per juta token, yaitu 0,025 dari harga input dasar atau 2,5% dari US$10 per juta token. Angka tersebut penting bagi agen yang berulang kali membaca instruksi sistem, basis pengetahuan, atau konteks proyek yang sama.

Konteks 1 juta token tidak berarti setiap tugas harus mengirim satu juta token. Context window adalah kapasitas maksimum yang didukung, bukan resep penggunaan. Konteks yang terlalu besar dapat menaikkan biaya, memperumit penelusuran informasi relevan, dan membuat evaluasi sulit direproduksi jika isi konteks berubah. Sebaliknya, konteks yang cukup luas dapat berguna pada repositori besar, dokumen panjang, atau kerja agen yang harus mempertahankan banyak keadaan.

Output maksimum 128 ribu token juga bukan jaminan bahwa keluaran panjang adalah keluaran baik. Pada beberapa workflow, output panjang dibutuhkan untuk membuat artefak atau menjelaskan perubahan. Pada workflow lain, keluaran yang diinginkan hanya tindakan terstruktur, ringkasan singkat, atau patch kecil. Metrik kualitas harus mencocokkan bentuk keluaran yang memang diperlukan.

Harga input dan output perlu dipisahkan dari klaim biaya per tugas. Harga per token memberi komponen yang mudah dihitung. Biaya per tugas memerlukan data tambahan: jumlah token masuk dan keluar, cache hit, tool call, retry, serta tingkat keberhasilan pada tugas nyata. Dua sistem dengan tarif token sama dapat menghasilkan total biaya berbeda bila salah satunya membutuhkan lebih banyak putaran untuk mencapai hasil yang diterima.

Cache read sebesar 2,5% dari tarif input dasar dapat mengubah perhitungan untuk konteks yang stabil dan dibaca ulang. Namun manfaatnya bergantung pada pola lalu lintas yang benar-benar cocok dengan mekanisme cache. Jika setiap permintaan membawa dokumen baru, atau jika instruksi terus berubah, asumsi penghematan berbasis cache tidak boleh dipakai tanpa pengukuran.

Dalam memilih model, masukkan kapasitas konteks dan harga ke dalam eksperimen yang sama dengan kualitas. Catat ukuran konteks, token keluaran, panggilan alat, waktu respons, dan hasil pemeriksaan manusia. Dengan begitu, harga bukan sekadar angka dalam tabel spesifikasi, melainkan salah satu variabel dalam biaya menyelesaikan pekerjaan.

Pengumuman Anthropic memberi dua catatan yang sering hilang ketika tabel benchmark berubah menjadi gambar ringkas di media sosial. Pertama, standard error Terminal-Bench Science 0.1 adalah ±3,5 hingga 4,5 poin per model. Kedua, Fable 5.1 dievaluasi dengan safeguard produksi aktif, dan pada tugas ketika safeguard tersebut melakukan intervensi, Fable 5.1 maupun Fable 5 dapat memperoleh skor nol pada OSWorld 2.0.

Standard error tidak menghapus hasil 64,6% dan 52,6%. Namun ia memberi batas pada kepastian yang dapat ditarik dari satu angka. Selisih 12 poin pada Terminal-Bench Science lebih besar daripada rentang standard error yang dicantumkan Anthropic untuk tiap model, tetapi pembacaan yang benar tetap harus mencatat bahwa evaluasi mengandung variasi. Jangan membulatkan hasil menjadi klaim bahwa satu sistem pasti unggul pada setiap pengulangan, tugas, atau harness.

Skor nol akibat safeguard memiliki makna metodologis lain. Dalam evaluasi produksi, safety layer adalah bagian dari sistem yang benar-benar dipakai pengguna. Menghilangkannya agar skor lebih tinggi mungkin menghasilkan ukuran kemampuan mentah yang berbeda, tetapi tidak lagi mengukur produk yang sama. Anthropic menyatakan bahwa pada intervensi safeguard lain, tugas keamanan siber diselesaikan oleh Claude Opus 4.8 dan tugas biologi oleh Claude Opus 5; perusahaan itu juga mengatakan hal tersebut kemungkinan menurunkan performa Fable 5.1 dan Fable 5 pada benchmark terkait.

Catatan ini tidak memberi alasan untuk membuang hasil Fable 5.1, atau mengoreksi skor secara spekulatif. Sebaliknya, catatan itu menjelaskan mengapa pembaca perlu menanyakan sistem apa yang sedang diuji. Apakah yang diukur model tanpa pembatasan? Model dengan safeguard produksi? Atau sebuah orkestrasi yang mengalihkan sebagian tugas ke model lain? Ketiganya dapat relevan, tetapi jawabannya tidak dapat disamakan.

OSWorld 2.0 memperlihatkan nilai dari pelaporan dua metrik. Fable 5.1 berada pada 77,9% partial dan 41,7% strict. Jika produk hanya memberi nilai ketika tugas selesai sepenuhnya, skor strict mungkin lebih dekat dengan risiko bisnis. Bila alur kerja memungkinkan manusia meninjau dan menyelesaikan bagian yang tersisa, skor parsial juga mengandung informasi. Tidak ada satu angka yang wajib dipakai tanpa melihat bagaimana pekerjaan ditutup di dunia nyata.

Ketidakpastian bukan kelemahan komunikasi. Ia adalah bagian dari kejujuran evaluasi. Tabel yang menyebut versi, error, safeguard, dan definisi sukses memberi pembaca kesempatan untuk menilai apakah hasilnya relevan. Tabel yang hanya menampilkan angka besar memberi kesan pasti, tetapi menyembunyikan kondisi yang menentukan arti angka itu.

ARC-AGI mengukur kemampuan menyelesaikan masalah abstraksi dan generalisasi baru melalui tugas grid. Ini bukan benchmark terminal, desktop, CAD, atau pengetahuan dengan alat. Karena perbedaannya, ARC-AGI tidak bisa dipakai untuk membatalkan hasil Terminal-Bench atau BenchCAD. Nilainya terletak pada fungsi lain: menyediakan pengukuran independen pada jenis tugas yang berbeda, dengan aturan dan leaderboardnya sendiri.

ARC Prize melaporkan hasil independen pada ARC-AGI 1 dan ARC-AGI 2. Dalam kondisi max effort yang dirujuk, angka yang perlu dibaca adalah 97,5% pada ARC-AGI 1 dan 90% pada ARC-AGI 2. Kedua skor tersebut tinggi, tetapi bukan alasan untuk menganggap semua benchmark telah “terselesaikan”. ARC-AGI 1 dan ARC-AGI 2 adalah set tugas berbeda, dan hasil pada satu keluarga evaluasi tidak otomatis berpindah ke kemampuan menjalankan toolchain perangkat lunak atau mengoperasikan desktop.

Laporan teknis ARC Prize 2025 menjelaskan bahwa ARC-AGI-2 dirancang dengan kompleksitas tugas lebih tinggi daripada pendahulunya. Laporan itu juga menekankan penggunaan set evaluasi privat untuk mengurangi risiko overfitting dan kontaminasi. Detail seperti ini menjelaskan mengapa nama dan versi benchmark harus ditulis lengkap. “Skor ARC” tanpa versi menyembunyikan perubahan dalam kumpulan tugas dan tingkat kesulitannya.

Independensi sumber juga penting, tetapi bukan sihir. Organisasi independen dapat memberi sudut pandang yang tidak bergantung pada tabel peluncuran vendor. Namun pembaca tetap perlu memeriksa konfigurasi, mode effort, jumlah upaya yang diizinkan, dan definisi pengiriman jawaban. “Independen” menjelaskan siapa yang mengelola evaluasi, bukan bahwa semua hasil otomatis dapat dibandingkan dengan semua tabel lain.

Skor 97,5% pada ARC-AGI 1 dan 90% pada ARC-AGI 2 sebaiknya diperlakukan sebagai dua hasil spesifik pada kondisi max effort, bukan sebagai nilai IQ model. Mereka memberi bukti mengenai kinerja pada tugas abstraksi dan generalisasi ARC. Untuk klaim tentang agen profesional, pengembang masih memerlukan benchmark agen dan, yang lebih penting, evaluasi pekerjaan yang relevan.

Kombinasi sumber vendor dan independen dapat membangun gambaran yang lebih jujur bila perbedaannya tidak disamarkan. Tabel OpenAI menjawab sebagian pertanyaan tentang Astra dan Fable 5.1 pada benchmark yang ditampilkan. Tabel Anthropic menjawab sebagian pertanyaan tentang Fable 5.1, termasuk catatan safeguard dan ketidakpastian. ARC Prize menambah pengukuran lain. Tidak satu pun sendirian menetapkan peringkat universal.

Keputusan model sebaiknya dimulai dari daftar pekerjaan nyata, bukan dari daftar benchmark. Kumpulkan contoh tugas yang mewakili pekerjaan berisiko tinggi, tugas paling sering, dan kasus yang biasanya gagal. Sertakan kondisi yang benar-benar akan berlaku: akses file, alat, batas waktu, format keluaran, proses persetujuan, serta kapan agen harus berhenti dan meminta manusia.

• Tetapkan definisi sukses yang dapat diperiksa untuk setiap tugas.
• Pisahkan keberhasilan penuh, keberhasilan parsial, dan kegagalan yang menimbulkan risiko.
• Jalankan kedua model dengan alat, prompt, batas waktu, dan anggaran yang sama sejauh mungkin.
• Catat effort, jumlah iterasi, token input dan output, cache, tool call, serta retry.
• Uji beberapa kali bila tugas atau eksekusinya bersifat stokastik.
• Tinjau keluaran buta terhadap identitas model bila prosesnya memungkinkan.
• Dokumentasikan versi model, versi benchmark internal, dan tanggal evaluasi.

Daftar ini bukan resep untuk membangun leaderboard baru. Tujuannya adalah membuat keputusan dapat ditelusuri. Jika model A lebih banyak menyelesaikan tugas tetapi biayanya jauh lebih tinggi, catatan harus menunjukkan seberapa tinggi dan pada tugas apa. Jika model B gagal lebih jarang pada format keluaran kritis, fakta itu harus muncul bahkan bila benchmark publiknya kurang menguntungkan.

Gunakan benchmark publik untuk memilih hipotesis yang akan diuji. Hasil Astra pada Terminal-Bench Science dapat menjadi alasan untuk memasukkan workflow terminal ilmiah ke dalam evaluasi internal. Hasil BenchCAD dapat menjadi alasan untuk menguji kumpulan render dan file CAD perusahaan. Hasil OSWorld partial dan strict dari Fable 5.1 dapat mendorong pemisahan metrik desktop antara kemajuan dan penyelesaian penuh. Benchmark memberi bahasa dan titik awal; ia tidak menulis rancangan uji untuk Anda.

Hindari eksperimen yang hanya mengukur jawaban pertama apabila produk akan menjalankan agen multi-langkah. Demikian pula, jangan menguji agen dengan alat penuh bila produk sesungguhnya tidak memberi akses itu. Keselarasan antara evaluasi dan konfigurasi produksi lebih bernilai daripada angka yang mengesankan tetapi tidak relevan.

Terakhir, perlakukan hasil sebagai keputusan sementara yang dapat diperbarui. Versi model berubah, benchmark direvisi, harga bergeser, dan workflow internal berkembang. Simpan tugas evaluasi dengan aman, ulangi ketika konfigurasi penting berubah, lalu putuskan berdasarkan data terbaru yang memang mencerminkan pekerjaan Anda.

GPT-6 Astra memiliki hasil yang dilaporkan OpenAI sebesar 64,6% pada Terminal-Bench Science 0.1 dibanding 52,6% untuk Claude Fable 5.1, serta 95,9% pada BenchCAD dengan alat dibanding 84,3% untuk Fable 5.1. Itu adalah klaim numerik yang jelas dan berguna, selama benchmark dan sumbernya disebut. Fable 5.1 juga memiliki 55,8% pada Terminal-Bench 4.0, 77,9% partial dan 41,7% strict pada OSWorld 2.0, serta 60,9% pada HLE tanpa alat dan 65,0% dengan alat menurut Anthropic.

Fakta berikutnya sama pentingnya: hasil tersebut berasal dari beberapa protokol. Benchmark, versi tugas, harness, effort, alat, anggaran, definisi sukses, dan safeguard dapat mengubah apa yang sebenarnya diukur. Anthropic mencatat standard error ±3,5 hingga 4,5 poin per model pada Terminal-Bench Science 0.1 dan menjelaskan kemungkinan skor nol ketika safeguard produksi melakukan intervensi. ARC Prize menambah hasil independen 97,5% pada ARC-AGI 1 dan 90% pada ARC-AGI 2 pada max effort, tetapi evaluasi itu mengukur keluarga tugas yang berbeda.

Claude Fable 5.1 membawa spesifikasi yang relevan bagi perhitungan produksi: konteks 1 juta token, output maksimum 128 ribu token, US$10 per juta token input, US$50 per juta token output, dan cache read pada 0,025 dari harga input dasar. Spesifikasi ini membantu memperkirakan desain sistem, tetapi tidak sendiri menentukan biaya pekerjaan selesai.

Jadi tidak ada pemenang tunggal yang dapat dibuktikan dari benchmark yang dibahas di sini. Ada keunggulan yang dilaporkan pada tugas tertentu, metrik yang berbeda arah pada tugas lain, dan kondisi evaluasi yang harus dibaca bersama angkanya. Pilihan yang bertanggung jawab adalah memeriksa sumber, menyebut protokol, lalu menguji kedua model pada pekerjaan nyata dengan aturan yang sama. Itu mungkin kurang dramatis daripada mahkota “terbaik”, tetapi jauh lebih dekat dengan informasi yang diperlukan untuk mengambil keputusan.

Sumber individual:

• OpenAI: GPT-6 Astra: A new generation of intelligence
• Anthropic: Introducing Claude Fable 5.1 and Claude Mythos 5.1
• Dokumentasi Claude: Claude Fable 5.1
• ARC Prize
• ARC Prize 2025: Technical Report