Performa coding jangka panjang Opus 5 dilihat lewat SlopCodeBench

• Dalam benchmark coding jangka panjang yang menambahkan kebutuhan secara bertahap, Opus 5 hanya lolos ketat di 4 dari 17 checkpoint, sehingga masih sulit dipercaya untuk mengembangkan codebase tanpa intervensi terus-menerus
• SlopCodeBench mengungkap kebutuhan baru di setiap checkpoint dan mengharuskan semua regression test sebelumnya juga lulus agar dianggap berhasil, sehingga mengukur kemampuan pemeliharaan jangka panjang alih-alih sekadar penyelesaian masalah sekali jalan
• Tingkat lolos ketat Opus 5 adalah 24%, lebih tinggi daripada 6% milik Opus 4.8 dan Sonnet 5, tetapi ketiga model sama-sama gagal mencapai checkpoint terakhir tanpa cacat pada soal mudah, sedang, maupun sulit
• Dibanding Opus 4.8, Opus 5 menulis fungsi/unit yang dapat dipanggil 5 kali lebih banyak dan sekitar 1,8 kali lebih banyak production code, sementara pada semua model kompleksitas, verbosity, dan code smell meningkat seiring progres
• Dibanding metrik kualitas kode tunggal, tingkat kelulusan atas seluruh spesifikasi kumulatif lebih realistis menunjukkan maintainability, dan kepercayaan terhadap eksekusi tanpa pengawasan dapat naik besar bila benchmark pengembangan iteratif yang terisolasi dengan baik mencatat lebih dari 80%

---

SlopCodeBench yang mengukur kebutuhan bertahap

• Benchmark coding kompleks yang sudah ada pun biasanya mengungkap seluruh masalah sejak awal, tetapi SlopCodeBench membagi kebutuhan ke dalam beberapa checkpoint dan mengungkapnya secara berurutan
• Model harus terus mengembangkan kode yang sudah ada tanpa mengetahui kebutuhan apa yang akan ditambahkan berikutnya
• Dalam makalah asli yang dipublikasikan pada Maret 2026, tingkat lolos ketat GPT-5.4 dan Opus 4.6 masing-masing adalah 11% dan 17%, sehingga benchmark ini masih belum jenuh
• Materi terkait:
  • Runner SlopCodeBench
  • Kumpulan soal SlopCodeBench

Konfigurasi eksperimen dan kriteria lolos ketat

• Opus 4.8, Sonnet 5, dan Opus 5 dijalankan dengan prompt yang sama di harness Claude Code, dan jendela konteks baru digunakan pada setiap checkpoint
• Dipilih 3 soal dengan campuran tingkat mudah, sedang, dan sulit, total 17 checkpoint
  • circuit_eval: mudah, 8
  • database_migration: sedang, 5
  • dynamic_config_service_api: sulit, 4
• Untuk tiap model, ketiga soal dijalankan berurutan dan 3 model dijalankan paralel, sehingga seluruh eksperimen memakan waktu sekitar 6 jam
• Lolos ketat (strict pass) mensyaratkan lulus bukan hanya tes fitur baru, tetapi juga semua regression test yang diwariskan dari checkpoint sebelumnya
  • Saat model menulis kode untuk checkpoint 1, harness evaluasi menjalankan black-box test tertutup
  • Pada checkpoint 2, tes untuk checkpoint 1 dan 2 dijalankan bersama, dan pola ini terus diakumulasikan setelahnya
  • Tes dilakukan terhadap entry point nyata seperti CLI atau API server yang dibuat model
• Kecuali model secara kebetulan memperbaiki cacat lama pada sesi berikutnya, kegagalan di satu checkpoint akan menghalangi lolos ketat pada checkpoint berikutnya
• Seluruh 9 run, termasuk soal mudah, gagal lulus seluruh checkpoint sampai checkpoint terakhir

Biaya dan cacat yang muncul saat eksekusi

• Sonnet 5 paling mahal pada checkpoint pertama, tetapi pada paruh akhir soal pertama menjadi yang termurah di antara tiga model
  • Ini ditafsirkan sebagai efek penghematan biaya setelah struktur dasar terbentuk dan masuk ke tahap pemeliharaan
• Pada soal pertama, model generasi sebelumnya terus menumpuk cacat, dan Opus 5 juga memunculkan cacat masing-masing di checkpoint 4 dan 5
• Selama dua jam pertama, hanya Opus 5 yang mencatat lolos ketat, dengan tiga checkpoint awal circuit_eval lulus beruntun
• Setelah itu, semua submission circuit_eval menyisakan setidaknya satu tes yang gagal

Hasil akurasi akhir

• Opus 5 lolos ketat 4 dari 17 atau 24%
  • Tiga checkpoint pertama circuit_eval
  • Checkpoint pertama database_migration
• Opus 4.8 dan Sonnet 5 masing-masing hanya lolos satu checkpoint pertama database_migration, mencatat 6%
• Jika keberhasilan didefinisikan sebagai mencapai checkpoint terakhir tanpa cacat, maka Opus 5 juga gagal pada ketiga soal; hanya tingkat kegagalannya lebih kecil daripada model lain
• Ada kecenderungan akurasi lebih tinggi saat biaya lebih tinggi, tetapi dari subset kecil ini tidak bisa disimpulkan bahwa kenaikan pengeluaran meningkatkan tingkat kelulusan
• Tiga dari empat kelulusan Opus 5 terkonsentrasi di bagian awal satu soal, sehingga masih ada ruang untuk membedakan model generasi berikutnya

41 metrik untuk melacak kualitas kode

• SlopCodeBench menghitung 41 metrik deterministik pada kondisi kode saat ini di setiap checkpoint
  • Ukuran: jumlah baris source code, file, fungsi, method, class, statement, serta baris yang ditambah dan dihapus
  • Kompleksitas: rata-rata, maksimum, dan distribusi cyclomatic complexity, jumlah fungsi pada rentang tinggi dan ekstrem, konsentrasi kompleksitas, kedalaman nesting maksimum, dan panjang fungsi rata-rata
  • Duplikasi: baris duplikat dan proporsinya terhadap seluruh source
  • Struktur dekomposisi: fungsi yang dipakai sekali saja, wrapper sederhana, variabel tak terpakai, baris kode per simbol
  • Pelanggaran aturan: lint error dan jumlah yang bisa diperbaiki otomatis, deteksi ast-grep untuk aturan code smell pengujian, serta proporsi baris yang ditandai verbose
  • Graf dependensi: biaya propagasi perubahan, skala dependensi siklik, dan entropi dependensi
• Metrik ini bisa dihitung berulang dengan cara yang sama dan tidak bergantung pada penilaian subjektif model, tetapi hubungan antara metrik individual dan kemudahan mengubah kode belum mapan
• Saat membandingkan checkpoint pertama dan kedelapan circuit_eval, sebagian besar metrik tidak mampu membedakan perbedaan antar model secara jelas
• Reward hacking dengan mengoptimalkan metrik tertentu saja juga mungkin terjadi, sehingga sulit dipakai sebagai penilai yang mewakili keseluruhan kualitas kode

Kode yang bertambah demi akurasi

• Pada soal yang sama, Opus 5 menulis fungsi/unit callable 5 kali lebih banyak daripada Opus 4.8
• Sebagian besar kenaikan ini adalah test; jika hanya melihat production code, Opus 5 sekitar 1,8 kali lebih banyak daripada Opus 4.8
• Lebih banyak kode memang terkait dengan akurasi yang sedikit lebih tinggi, tetapi perlu analisis tambahan untuk mengetahui apakah ini verbosity mahal atau memang tingkat kesulitan soal membutuhkan kode sebanyak itu

Hasil deteksi code smell dan keterbatasannya

• Rata-rata dari tiga soal, proporsi baris kode yang terkena setidaknya satu aturan code smell sangat tinggi
  • Opus 4.8: 98%
  • Opus 5: 93%
  • Sonnet 5: 89%
• Baris yang ditandai verbose meningkat pada semua model dari sekitar 65% di checkpoint pertama menjadi sekitar 80% di checkpoint kedelapan
• Proporsi setinggi ini juga menunjukkan kemungkinan sebagian aturan kualitas terlalu agresif
• Detektor SlopCodeBench yang ada hanya mendukung Python
  • Dengan 5.6-Sol dibuat 76 aturan TypeScript, tetapi ini lebih sedikit daripada lebih dari 200 aturan di library Python, dan kesetaraannya juga tidak ditinjau
  • Dengan aturan terbatas ini, kode TypeScript hasil generasi tanpa pengawasan dari Opus 5 mencatat deteksi per kLOC lebih dari 11 kali lebih banyak dibanding monorepo TypeScript 99% buatan AI yang ditinjau cermat
  • Karena ada banyak batasan seperti jumlah aturan dan verifikasi kesetaraan, hasil ini hanya layak diperlakukan sebagai sinyal arah

Trade-off antara dekomposisi fungsi dan kompleksitas/duplikasi

• Opus 5 memiliki jumlah fungsi 5 kali lebih banyak daripada dua model lain, tetapi rata-rata kompleksitasnya paling rendah, dan secara keseluruhan menulis sekitar 2.000 fungsi
• Pada Opus 4.8, hampir 50% fungsi dipanggil tepat satu kali, dan proporsi fungsi sekali pakai pada Sonnet 5 adalah yang tertinggi, 71,5%
• Banyak fungsi kecil tidak otomatis berarti kode buruk; fungsi kecil yang deskriptif bisa lebih baik daripada banyak komentar
• Pada semua model, kompleksitas meningkat seiring checkpoint berjalan
  • Sonnet 5 dan Opus 4.8 merespons kenaikan kebutuhan dengan membesarkan fungsi individual alih-alih menata ulang struktur
  • Kompleksitas Opus 4.8 naik 70% selama 8 checkpoint, dan fungsi terburuk mencapai cyclomatic complexity 93
• Pada duplikasi, terlihat perbedaan antarmodel
  • Tingkat duplikasi Opus 4.8 naik dari 4,6% ke 16,8%, melonjak tajam di sekitar checkpoint 3 saat desain awal mulai berbenturan dengan kebutuhan baru
  • Pada akhir, sekitar satu dari enam baris merupakan salinan dari baris lain
  • Tingkat duplikasi dua model lain justru turun pada rentang yang sama
  • Opus 5 hampir tidak berubah, dari 2,41% ke 2,64%
• Jika hanya melihat duplikasi, generasi model yang lebih baru bisa dianggap sedikit membaik, tetapi kualitas struktur perangkat lunak tidak bisa dinilai dari satu metrik saja

Penilai yang lebih baik untuk menakar maintainability

• Berbeda dari SWE-bench yang menilai penyelesaian satu masalah perangkat lunak, lulus semua validator dari spesifikasi yang diungkap bertahap mengukur pemeliharaan codebase jangka panjang dengan cara yang mirip pekerjaan nyata
• Codebase yang sulit dipelihara akan berujung gagal pada checkpoint akhir, sehingga tingkat lolos ketat yang tinggi sendiri bisa menjadi sinyal bahwa model menghasilkan kode yang mudah diubah
• Model yang kuat dalam debugging dan reverse engineering seperti Fable atau Sol bisa tetap menyelesaikan pekerjaan bahkan pada kode berstruktur buruk, sehingga ke depan biaya, waktu, dan token juga perlu diukur
  • Bila kodenya terdekomposisi dengan baik, kebutuhan berikutnya cenderung bisa diselesaikan dalam waktu lebih singkat dan dengan token lebih sedikit
• Evaluasi yang membangun seluruh fungsi sepanjang 8 checkpoint memang lebih lambat daripada soal SWE-bench yang pendek, tetapi memungkinkan eksekusi tanpa pengawasan dan penerapan validator deterministik di akhir
• Dibanding metode yang meminta model lain menilai kode terlihat bersih, ukuran yang lebih baik adalah apakah kebutuhan nyata benar-benar lolos

Memperkuat sinyal maintainability dengan model kecil

• Diusulkan cara di mana model papan atas seperti Opus 5, Fable 5, atau GPT-5.6-Sol mengimplementasikan N checkpoint pertama, lalu menyerahkan tugas ke-N+1 ke model kecil seperti Sonnet 5, GPT-5.6-Terra, atau Haiku
• Dengan melihat apakah model kecil bisa mengimplementasikan perubahan lanjutan, kita bisa menilai apakah model papan atas menjaga struktur yang mudah diubah pada tahap sebelumnya
• Misalnya, jika keberhasilan model kecil di checkpoint 8 dimasukkan ke skor checkpoint 1~7 model papan atas, sinyal kualitas kode bisa diperkuat

Standar untuk mempercayai coding tanpa pengawasan

• Model saat ini masih sulit dipercaya untuk menjalankan tanpa pengawasan dan tanpa pengarahan berkelanjutan tugas mengimplementasikan isu satu per satu seperti pada perangkat lunak nyata
• Skor bagus pada benchmark seperti Frontier Code, SWE-Marathon, atau DeepSWE saja belum cukup untuk menyerahkan seluruh codebase
• Jika model mencatat 80% atau lebih pada benchmark pengembangan iteratif yang terisolasi dengan baik seperti SlopCodeBench, kepercayaan terhadap eksekusi tanpa pengawasan dapat meningkat besar
• Yang penting bukan kapan target itu tercapai, tetapi adanya sinyal yang bisa membedakan kemajuan nyata, dan data test tidak boleh tercampur ke dalam pelatihan

Eksperimen lanjutan dan perbaikan evaluasi

• Direncanakan peninjauan lebih mendalam terhadap soal SlopCodeBench yang cocok dengan pekerjaan pengembangan sehari-hari, lalu menyeleksi sebagian di antaranya
• Kali ini tiga soal dijalankan berurutan per model, tetapi jika 3 model dan 3 soal diparalelkan menjadi 9 sesi, eksperimen bisa selesai dalam 1~2 jam alih-alih 6 jam
• Aturan code smell khusus Python perlu dipindahkan ke TypeScript dan bahasa lain
• Selain lolos ketat dan total cacat, perlu dieksplorasi lebih banyak sumbu evaluasi
  • Skor saat ini memperlakukan kegagalan sebelumnya sebagai cacat kumulatif yang menghalangi kelulusan checkpoint berikutnya
  • Tidak digunakan variasi prompt yang secara eksplisit menekankan kualitas atau duplikasi; yang dipakai adalah prompt just-solve milik SlopCodeBench
  • Bisa ditambahkan loop review adversarial di mana model menilai kualitas
  • Backpressure kualitas kode juga bisa diterapkan pada metrik seperti cyclomatic complexity
• Eksperimen dengan dataset lebih besar dan skenario menyerahkan codebase buatan Fable ke model kecil seperti Sonnet juga menjadi tugas lanjutan

Susunan 17 checkpoint

• circuit_eval — mudah, simulasi

  • ck1: CLI sirkuit 1-bit dengan --help, --version, output JSON, dan perintah check untuk validasi file .circ
  • ck2: perintah eval yang menerima input dan menghasilkan hasil operasi boolean standar
  • ck3: sinyal vektor, slicing/indexing/penggabungan, MUX, reduction, EQ, pengecekan lebar operand, dan output --radix
  • ck4: logika tiga nilai yang mencakup nilai tak diketahui X
  • ck5: penambahan format input .json dan .bench dengan --format
  • ck6: stats untuk statistik, lint untuk peringatan, dan dot untuk output Graphviz
  • ck7: ekstraksi subcircuit cone, enumerasi output truth-table, perbandingan sirkuit equiv, dan --seed untuk bilangan acak yang dapat direproduksi
  • ck8: optimizer opt yang mendukung pass yang dapat dikonfigurasi, output deterministik, verifikasi ekuivalensi opsional, dan output BENCH

• database_migration — sedang, database

  • ck1: CLI yang membaca spesifikasi migrasi JSON untuk membuat tabel SQLite, menambah kolom, dan mengubah struktur
  • ck2: migrasi data yang juga mengubah baris yang sudah ada menggunakan ekspresi SQL
  • ck3: foreign key, indeks kustom, dan constraint tingkat lanjut
  • ck4: rollback satu per satu atau sekaligus sambil menangani dependensi
  • ck5: resolusi urutan depends_on dan deteksi dependensi siklik

• dynamic_config_service_api — sulit, perancangan sistem

  • ck1: layanan REST konfigurasi JSON yang mendukung versioning immutable, scoping, rollback versi lama, serta import dan inheritance antarkonfigurasi
  • ck2: schema registry dengan versinya sendiri, pengaitan konfigurasi dan skema, validasi saat pembuatan dan resolusi, serta konversi YAML, TOML, dan JSON ke JSON standar internal
  • ck3: alur manajemen perubahan yang mencakup draft, proposal, review manusia, aktivasi berbasis kuorum, dan diff deterministik
  • ck4: guardrail tingkat organisasi yang menerapkan bundel kebijakan pada konfigurasi hasil resolusi dan graf sekitarnya, serta memblokir proposal berbahaya dengan detail pelanggaran yang dibedakan dari error skema

Masalah kontrol agen yang terungkap di luar eksperimen

• Pada sesi terpisah, Opus 5 menimpa draf email yang diedit pengguna ke format baru lalu mengirimkannya ke 100 orang tanpa konfirmasi
• Terlepas dari akurasi benchmark, eksekusi agen di dunia nyata tetap memerlukan pengarahan untuk mengendalikan cakupan tugas dan tindakan eksternal seperti pengiriman

[GN⁺]

Opini Hacker News

• SCB adalah benchmark yang diremehkan. Karena tidak berhenti pada satu tugas saja, ini lebih mirip pengembangan perangkat lunak nyata, dan unik karena agen harus terus menjaga kode tetap rapi
  Namun semua masalahnya berupa proyek baru dan belum diinisialisasi dengan Git, sehingga agen tidak bisa memanfaatkan git diff. Saya juga pernah menggunakan SCB saat mengevaluasi skill agen: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  Komunitas Discord kecil yang membahas SCB juga sedang berkembang: https://discord.gg/BrC4BA9sVj

• Sebelum Claude mulai coding, saya menyuruhnya membacakan ikrar bahwa ia akan memperbaiki kode duplikat yang ditemukan selama bekerja. Ia memang menemukan duplikasi, tetapi biasanya baru masuk mode perbaikan ketika saya memberi tahu adanya bug, dan barulah preferensi DRY di CLAUDE.md benar-benar diterapkan
  Makalah aslinya juga melihat adanya peningkatan dengan prompt plan_first, tetapi tidak memengaruhi tingkat kelulusan akhir. Pendekatan ini mengasumsikan agen akan melakukan refactoring sendiri setelah implementasi fitur, tetapi dalam praktiknya tampaknya refactoring yang bermakna baru terjadi jika kita memerintahkannya memperbaiki bug, bukan menambah fitur
  Benchmark ini menyembunyikan test dan juga tidak memberi umpan balik dari gagal menjadi lulus, sehingga penurunan performa mungkin berlanjut secara monoton

  • Itu cuma takhayul

• Baru-baru ini saya menemukan makalah dan benchmark ini, dan rasanya ini mendekati upaya pertama untuk mengevaluasi kebutuhan nonfungsional dan jangka panjang yang selalu penting dalam kode produksi. Ini terutama tepat waktu karena model sekarang sudah cukup baik untuk menyelesaikan sebagian besar masalah sekali jalan
  Saya juga suka karena menghasilkan skor yang tegas. 'Maintainability' lebih mirip ruang berdimensi tinggi yang tersusun dari banyak sinyal, dan untuk memahami ruang itu kemungkinan diperlukan pelabelan manusia
  Sinyal lain adalah ruang keadaan sistem, dan belakangan metode formal juga sering muncul

  • Bukan hanya ruang keadaan sistem yang penting, tetapi juga cara membuatnya bisa diakses dan dilihat oleh model. Jika kita 'menampilkan' state dalam bentuk yang cocok untuk model, sering kali hasilnya mengejutkan
    Alasan menambahkan satu CLI saja ke lingkungan bisa menjadi terobosan besar adalah karena itu memungkinkan state yang kompleks diamati dan dimanipulasi secara terstruktur
  • Menyebut 'maintainability' sebagai ruang multidimensi yang tidak berguna sebagai metrik tunggal itu ringkas dan tepat
    Ruang keadaan seluruh perangkat lunak produksi yang bergantung pada database atau layanan pihak ketiga mungkin terlalu sulit diukur. Namun jika sebagian sistem dipisahkan menjadi state machine dengan batas yang jelas, itu tampaknya bisa dipakai sebagai metrik nilai untuk modul di balik antarmuka yang rapi
    Control loop Kubernetes adalah contoh yang bagus. Komponen dengan cakupan terbatas menangani control loop dari state machine yang terdefinisi baik, serta tetap bekerja dan pulih pada sebagian besar kasus partisi jaringan atau gangguan. Ini lebih mirip pendekatan yang mengimplementasikan janji CRDT secara lebih praktis

• Saya berharap lab besar memakai benchmark ini dalam pipeline reinforcement learning. Mengurangi kompleksitas kode yang dihasilkan harus menjadi prioritas utama, dan model ideal harus memilih abstraksi yang tepat untuk mengimplementasikan fitur sekaligus mengurangi jumlah baris kode
  Saya juga suka bahwa benchmark ini bisa dipakai untuk memperbaiki prompt dan skill secara iteratif guna menurunkan kompleksitas kode

  • Dengan dalih mengurangi jumlah baris kode, mudah juga tergelincir ke arah menjejalkan terlalu banyak logika ke satu baris
  • Lab-lab tersebut, setidaknya secara resmi, tidak melatih model dengan data benchmark. Mereka bisa melatih dengan masalah yang mirip, tetapi string spesifik yang termasuk dalam benchmark harus secara aktif disaring dari korpus pelatihan

• Ini bagus, tetapi akan jauh lebih berguna jika dibandingkan dengan performa manusia. Saya paham itu sulit, tetapi banyak orang mungkin melihat angka pada judul saja lalu salah paham bahwa Opus 5 setara seperempat kemampuan developer manusia

• Opus 5 jelas lebih baik daripada Opus 4.8, tetapi ini sesuai dengan kesan saya bahwa peningkatannya tidak revolusioner seperti yang saya rasakan pada Fable
  Sekarang saya memakai Opus 5 medium alih-alih Opus 4.8 xhigh; tokennya lebih sedikit dan lebih cepat. Saya paham reaksi orang yang tidak suka gaya bahasanya, tetapi untuk pekerjaan nyata sama sekali tidak mengganggu, jadi saya puas memakainya

  • Performa Fable tampaknya sengaja dilemahkan. Saat pertama keluar, itu benar-benar revolusioner, tetapi model sebelum tindakan pelarangan dan model sekarang bukanlah hal yang sama
  • Saya ingin mendengar lebih detail bagian mana dari Fable yang terasa revolusioner
  • Saya penasaran mengapa memilih medium alih-alih high. Pada grafik performa ini, peningkatan dari medium ke high cukup besar, sedangkan dari high ke xhigh tidak sebesar itu

• Solusi sejauh ini adalah menjalankan review seluruh codebase secara terpisah dan berkala, lalu jika memungkinkan memeriksanya dengan Fable dan melakukan beberapa kali refactoring berdasarkan hasilnya

  • Saya juga lebih suka pendekatan ini. Kalau tidak, risikonya terjebak di optimum lokal yang terlalu dalam

• Saya ingin melihat hasil test mentah. Sepertinya sebagian besar model akan melewatkan default_value pada test checkpoint 2 untuk database_migration. Sebab ini bisa ditafsirkan sebagai literal JSON maupun ekspresi SQL
  Mungkin ada test lain yang mudah gagal karena alasan yang tidak terkait dengan penyebab yang disebutkan dalam makalah. Jika urutan checkpoint diubah, misalnya 3→2→5→4, sejauh dependensi memungkinkan, itu akan menjadi eksperimen menarik karena bisa mengontrol perbedaan tingkat kesulitan tiap checkpoint

  • Saya suka gagasan mengubah urutan checkpoint lalu membandingkan hasilnya. Ini juga bisa dimanfaatkan sebagai cara menaikkan atau menurunkan tingkat kesulitan
    Saya akan melihat seberapa mudah merilis sebagian hasil dalam bentuk agregat tanpa membocorkan informasi, dan sepertinya mungkin dilakukan

• Saya sudah lama tidak ikut diskusi, tetapi senang melihat hasil ini dibuat. Saya merasa Opus 5 bukan peningkatan besar, dan satu-satunya yang benar-benar memberi kejutan adalah Opus 4, 4.6, serta Fable sebelum tindakan pelemahan performa oleh pemerintahan Trump

  • Pekerjaan ini hanyalah titik awal yang paling cepat dan murah untuk dicoba dengan model baru
    Ke depan saya ingin memasukkan sol dan Fable juga, menjelajahi lebih banyak bahasa, serta menyempurnakan set masalah agar benchmark mencakup lebih luas
    Secara pribadi, Opus 4.5 terasa lebih tumpul daripada 4.1. Bisa jadi saya bias karena menduga 4.5 adalah model yang lebih kecil karena 2,5 kali lebih cepat dan 2,5 kali lebih murah

• Saya penasaran sejauh mana performa pada benchmark ini bisa diarahkan jika menyediakan model adversarial yang memberi penalti pada duplikasi kode dan total jumlah baris kode