Terminal-Bench 2.1: Panduan Coding Terminal Agentic

Terminal-Bench 2.1 itu tolak ukur (benchmark) untuk mengukur seberapa jago sebuah AI agent bekerja di dalam terminal — bukan cuma nulis potongan kode, tapi benar-benar menyelesaikan tugas nyata dari awal sampai selesai: pasang dependency, benerin build yang gagal, konfigurasi server, kelola repo git, sampai melatih model machine learning. Kalau Teman-Teman lagi cari cara memahami apa itu Terminal-Bench 2.1, kenapa versi ini muncul, dan bagaimana cara menjalankannya sendiri, tulisan ini mencoba merangkum semuanya dengan bahasa yang santai tapi tetap berisi.

Singkatnya: Terminal-Bench 2.1 adalah revisi dari Terminal-Bench 2.0 yang memperbaiki 28 dari 89 tugas, supaya skor yang keluar benar-benar mencerminkan kemampuan agent, bukan gara-gara lingkungan uji yang bermasalah. Benchmark ini dikembangkan bareng oleh Laude Institute, peneliti Stanford, dan komunitas open-source Terminal-Bench.

Apa Itu Terminal-Bench

Kalau Teman-Teman baru pertama dengar istilah ini, mari kita mulai dari yang paling gampang.

Bayangkan terminal itu seperti "meja kerja" seorang teknisi komputer. Di situ dia ngetik perintah untuk memasang program, membenahi error, menyalakan server, dan macam-macam lagi. Terminal-Bench pada dasarnya adalah kumpulan ujian praktik: agent AI dikasih sebuah tugas, dilepas di dalam sebuah lingkungan terisolasi (container), lalu dinilai apakah hasil akhirnya benar.

Yang bikin benchmark ini menarik adalah sifatnya yang berorientasi hasil (outcome-driven). Agent bebas pakai cara apa pun. Yang diperiksa bukan "perintah apa yang dia ketik", tapi "apakah kondisi akhir container-nya sesuai yang diminta". Setiap tugas punya empat komponen inti:

• Instruksi — deskripsi tugas dalam bahasa natural.

• Docker image — lingkungan awal berisi file dan paket yang relevan.

• Tes verifikasi — skrip yang memeriksa apakah tugas benar-benar beres.

• Solusi acuan (oracle) — solusi buatan manusia yang membuktikan tugas itu memang bisa diselesaikan.

Kenapa ini penting? Karena agent seperti Claude Code, Codex, dan Cursor sekarang sangat bergantung pada kemampuan mengeksekusi perintah terminal dengan benar. Satu langkah salah, langkah berikutnya ikut ambruk. Terminal-Bench menguji justru rantai kejadian panjang yang saling bergantung inilah — mirip kerjaan nyata seorang engineer.

Kenapa Terminal, Bukan Sekadar "Nulis Kode"?

Banyak benchmark coding cuma minta model menulis satu fungsi lalu dicek benar atau salah. Itu berguna, tapi jauh dari kenyataan kerja sehari-hari.

Di dunia nyata, sebuah tugas biasanya berbunyi begini: "Build kernel Linux dari source, lalu jalankan di QEMU" atau "Konfigurasi git server supaya push otomatis ter-deploy ke web server di port 8080". Ini bukan soal satu baris kode, tapi soal menavigasi lingkungan yang berantakan, membaca error, dan menyesuaikan strategi. Nah, di sinilah terminal jadi arena uji yang pas.

Kenapa Muncul Versi 2.1? Cerita di Balik Revisinya

Ini bagian yang menurutku paling menarik, karena menunjukkan benchmark yang bagus itu benda hidup, bukan sekali jadi lalu ditinggal.

Terminal-Bench 2.0 punya 89 tugas berkualitas tinggi. Tapi seiring waktu, tim menemukan bahwa sebagian skor rendah bukan karena agent-nya bodoh, melainkan karena tugasnya sendiri bermasalah. Maka lahirlah 2.1 yang membenahi 28 dari 89 tugas. Intinya: biar skor benar-benar mengukur kemampuan agent, bukan celah lingkungan.

Masalah yang diperbaiki dikelompokkan jadi tiga:

Hasilnya cukup terasa. Setelah revisi, tidak ada lagi tugas yang benar-benar mustahil diselesaikan di 2.1. Beberapa pasangan agent-model naik lumayan; salah satu lonjakan terbesar dilaporkan datang dari kombinasi Claude Code dengan Opus 4.6 yang naik belasan persen. Ada juga catatan penting: 2.1 disebut terinspirasi kerja "Terminal-Bench 2.0 Verified" dari Z.AI, dan sebagian perbaikan berasal dari laporan komunitas.

Pelajaran halusnya: kalau sebuah tugas gagal di semua percobaan dengan pola error yang sama, sering kali yang salah tugasnya, bukan modelnya. Ini prinsip yang berguna banget, bahkan buat kita yang bikin tes sendiri di kerjaan.

Prasyarat Sebelum Menjalankan Terminal-Bench 2.1

Sebelum praktik, mari siapkan dulu "alat perang"-nya. Jangan skip bagian ini, karena mayoritas error yang bikin frustrasi biasanya berakar dari prasyarat yang belum beres.

Yang perlu Teman-Teman siapkan:

• Docker — wajib. Semua tugas jalan di dalam container. Tanpa Docker, tidak ada cerita.

• Python 3.10+ — untuk harness dan tooling.

• uv (opsional tapi disarankan) — package manager Python yang cepat, sering dipakai di ekosistem ini.

• API key dari penyedia model yang mau diuji (misalnya OpenAI, Anthropic, Google, atau lewat penyedia seperti Together AI untuk model open-weight).

• Koneksi internet — karena banyak tugas boleh mengunduh paket. (Ini juga sumber sebagian masalah yang diperbaiki di 2.1, jadi wajar kalau hasilnya kadang bervariasi.)

• Sumber daya memadai — sebagian tugas berat (kompilasi, training model) butuh CPU/RAM lumayan, atau sandbox cloud.

Kenapa Docker itu inti? Karena benchmark ini menilai kondisi akhir sebuah lingkungan. Container memberi lingkungan yang bersih dan seragam setiap kali dijalankan, jadi hasil satu orang bisa dibandingkan dengan orang lain secara adil.

Getting Started: Cek Kesiapan

Sebelum lanjut, pastikan dulu Docker dan Python-nya hidup.

# Cek versi Docker
docker --version

# Cek Docker daemon benar-benar jalan
docker run hello-world

# Cek Python
python3 --version

Expected output (kurang lebih):

Docker version 27.x.x, build xxxxxxx
Hello from Docker!
This message shows that your installation appears to be working correctly.
Python 3.11.x

Kalau docker run hello-world gagal dengan pesan semacam Cannot connect to the Docker daemon, berarti Docker-nya belum nyala. Ini error paling umum nomor satu, dan kita bahas solusinya di bagian troubleshooting.

Cara Menjalankan Terminal-Bench 2.1 (Langkah demi Langkah)

Oke, sekarang bagian yang paling ditunggu. Terminal-Bench 2.1 didistribusikan lewat Harbor, framework untuk membangun dan menjalankan evaluasi agent dalam skala besar. Filosofinya: satu antarmuka, banyak agent, banyak benchmark.

Aku susun langkahnya berurutan biar gampang diikuti. Setiap langkah aku kasih alasan kenapa dia penting.

Step 1 — Pasang Harbor dan Tooling-nya

Kenapa ini duluan? Karena Harbor-lah "juru kunci" yang mengunduh dataset, menjalankan container, dan mengeksekusi tes.

Baca juga OpenCode Free: Agen AI Coding Gratis dan Open Source

# Bikin virtual environment biar rapi dan nggak ganggu sistem
uv venv
source .venv/bin/activate

# Pasang harbor (nama paket bisa berbeda; cek dokumentasi resmi terbaru)
uv pip install harbor

Expected output:

Installed 1 package in 320ms
 + harbor==x.y.z

Tips: Selalu kerja di dalam virtual environment. Ini menghindari konflik versi paket yang jadi biang kerok error misterius di kemudian hari.

Step 2 — Siapkan API Key sebagai Environment Variable

Agent butuh "otak", dan otak itu datang dari model lewat API. Kalau key-nya belum di-set, agent nggak bisa mikir.

export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
# atau penyedia lain sesuai model yang mau diuji

Kenapa penting: menaruh key di environment variable (bukan hardcode di file) itu praktik keamanan dasar. Jangan sampai key ke-commit ke git, ya. Ini kesalahan klasik yang bisa bikin tagihan membengkak.

Step 3 — Jalankan Benchmark-nya

Inilah momen intinya. Dataset 2.1 bisa dijalankan lewat registry Harbor. Perintahnya kurang lebih mengikuti pola versi sebelumnya ([email protected]), tinggal ganti ke versi 2.1:

harbor run -d [email protected] \
  --agent terminus-2 \
  --model gpt-5 \
  --n-attempts 3

Penjelasan tiap bagian:

• -d [email protected] — pilih dataset Terminal-Bench 2.1.

• --agent terminus-2 — pakai harness Terminus 2, "testbed netral" yang dibuat khusus untuk membandingkan performa antar-model secara adil.

• --model gpt-5 — model yang mau diuji (ganti sesuai kebutuhan).

• --n-attempts 3 — jumlah pengulangan per tugas. Skor biasanya dilaporkan sebagai pass@1 dirata-rata atas beberapa kali ulang untuk mengurangi faktor keberuntungan.

Expected output (ilustratif):

[harbor] Pulling dataset [email protected] ...
[harbor] Loaded 89 tasks
[harbor] Running task 1/89: configure-git-webserver ...
[harbor] Task passed ✓
[harbor] Running task 2/89: crack-7z-hash ...
[harbor] Task failed ✗
...
[harbor] Resolution rate: 54.0% (48/89)

Kenapa pakai Terminus 2? Karena tiap agent (Claude Code, Codex CLI, Gemini CLI, OpenHands, Mini-SWE-Agent) punya "kebiasaan" sendiri yang kadang di-tuning untuk model tertentu. Terminus 2 cuma punya satu alat — terminal headless — dan menyelesaikan tugas murni lewat perintah Bash. Jadi perbandingan antar-model jadi lebih apple-to-apple.

Step 4 — Baca dan Interpretasikan Hasilnya

Setelah selesai, Harbor akan menyimpan trajektori (rekaman langkah agent), log, dan skor akhir. Metrik utamanya:

• Resolution rate / pass@1 — persentase tugas yang berhasil.

• Token usage & cost — berapa banyak token dan biaya per tugas.

• Time per task — waktu rata-rata per tugas.

Kenapa jangan cuma lihat skor? Karena biaya dan waktu itu bagian dari cerita. Ada model yang skornya tinggi tapi boros token; ada juga tugas ekstrem yang bikin agent jalan sampai dua jam dan menghabiskan hampir 100 juta token. Untuk keputusan bisnis, rasio skor-terhadap-biaya sering lebih penting daripada skor mentah.

Step 5 — Debug Tugas yang Gagal

Kalau ada tugas gagal dan Teman-Teman curiga itu bug tugas (bukan bug model), analisis trajektorinya. Tim Terminal-Bench sendiri memakai alat debug berbasis LLM untuk membedakan "instruksi kurang jelas" versus "agent memang nggak mampu".

Prinsip praktisnya sederhana:

• Kalau semua percobaan gagal di tes yang sama dengan error mirip → curigai spesifikasi tugas.

• Kalau percobaan gagal dengan cara berbeda-beda → kemungkinan besar itu memang tingkat kesulitan yang wajar.

Tips Praktis Biar Nggak Kejeblos

Beberapa hal kecil yang sering bikin orang pusing:

• Sediakan sumber daya cukup. Tugas seperti kompilasi kernel atau training model butuh CPU/RAM lebih. Kalau di laptop biasa, pertimbangkan sandbox cloud seperti yang dipakai tim resmi (misalnya Daytona atau e2b).

• Jalankan beberapa kali. Karena ada faktor non-determinisme (hardware, API eksternal), satu kali run bisa menyesatkan. Rata-ratakan minimal 3 kali.

• Kunci versi dependency-mu sendiri kalau kamu bikin tugas turunan. Ini pelajaran langsung dari kenapa 2.1 harus lahir.

• Awas kebocoran data. Semua tugas ada di repo publik dengan canary string. Secara teori model bisa "nyontek" kalau dilatih di atas dataset ini. Jadi bacalah skor dengan sikap kritis.

Studi Kasus: Dari 2.0 ke 2.1

Biar lebih hidup, mari lihat perjalanannya seperti sebuah studi kasus.

Latar belakang. Terminal-Bench 2.0 dirilis dengan 89 tugas hasil crowdsourcing dari 93 kontributor yang total mengusulkan 229 tugas. Dari situ dipilih 89 yang terbaik lewat audit ketat — rata-rata tiap tugas dapat sekitar tiga jam perhatian reviewer. Serius, itu ratusan jam kerja manusia hanya untuk review.

Masalahnya. Meski sudah diaudit, praktik lapangan memunculkan celah: dependency yang berubah, anggaran sumber daya yang kurang, dan segelintir instruksi yang tak sinkron dengan tes. Akibatnya, sebagian skor rendah "salah alamat" — menyalahkan model padahal lingkungannya yang bocor.

Pendekatannya. Tim tidak mengganti tugas besar-besaran. Mereka melakukan bedah presisi pada 28 tugas: benahi dependency, longgarkan sumber daya, dan luruskan spesifikasi. Ditambah validasi berkelanjutan (continuous validation) supaya masalah serupa ketahuan lebih awal.

Hasilnya (dengan catatan angka bervariasi antar sumber). Mayoritas pasangan agent-model naik skornya di 2.1. Perbaikan paling dramatis terlihat pada tugas-tugas yang tadinya nyaris mustahil — beberapa yang sebelumnya 0% berhasil kini punya tingkat kelulusan positif. Dan yang paling penting: tidak ada lagi tugas yang sama sekali tak terpecahkan.

Pelajaran kunci.

• Benchmark yang baik butuh perawatan, bukan sekali rilis lalu dilupakan.

• Reproduktibilitas dan akses internet itu dua hal yang sering bertabrakan.

• Transparansi soal apa yang diperbaiki (tim mempublikasikan rincian per-tugas) membangun kepercayaan.

Perbandingan: Terminal-Bench 1.0 vs 2.0 vs 2.1

Supaya gampang dilihat sekilas, ini ringkasannya:

Dan kalau bicara memilih harness, ini panduan singkatnya:

Rekomendasi berdasarkan kebutuhan:

Baca juga ClinePass: Langganan Model Open Weight untuk Coding

• Mau riset perbandingan model murni → Terminus 2.

• Mau tahu performa nyata sebuah produk agent → pakai harness bawaan vendornya.

• Mau eksperimen open-source & bisa oprek → OpenHands atau Mini-SWE-Agent.

Soal Leaderboard dan Skor: Baca dengan Kepala Dingin

Ini bagian yang perlu kejujuran ekstra. Berbagai situs melaporkan angka Terminal-Bench 2.1 yang berbeda-beda dan sulit dibandingkan langsung, karena:

• Harness-nya beda. Skor model yang sama bisa berubah lumayan tergantung dipakai di Terminus 2, Codex CLI, atau mini-SWE-agent. Ada catatan bahwa skor sebuah model bisa "menyusut atau malah terbalik" begitu semua model dibaca di satu harness yang sama.

• Sumbernya beda. Ada yang melaporkan angka versi vendor (self-reported), ada yang hasil evaluasi independen seperti Artificial Analysis atau Vals AI.

• Sebagian angka menyebut model yang belum bisa aku verifikasi. Aku menemukan klaim skor untuk nama-nama model yang belum jelas keberadaannya, dengan angka yang saling bertentangan antar situs.

Jadi saranku: jangan telan satu angka bulat-bulat. Kalau butuh perbandingan untuk keputusan penting, buka langsung leaderboard resmi di tbench.ai atau evaluasi independen, dan pastikan harness serta metodologinya sama. Yang bisa dipegang dengan cukup pasti dari data yang kredibel: pada Terminal-Bench 2.0, model-model frontier terbaik masih di bawah 65%, sedangkan model kecil sekitar 15%. Angka di 2.1 cenderung lebih tinggi karena tugasnya lebih bersih — tapi tetap, itu benchmark yang berat.

Definisi cepat — pass@1: persentase tugas yang berhasil diselesaikan agent dalam satu percobaan, biasanya dirata-ratakan atas beberapa kali ulang supaya adil terhadap faktor keberuntungan.

Error Umum dan Cara Membereskannya

Berikut kumpulan masalah yang paling sering muncul, plus solusinya.

1. Cannot connect to the Docker daemon

Docker belum jalan.

# Linux
sudo systemctl start docker

# macOS: pastikan Docker Desktop sudah dibuka

Kenapa terjadi: daemon Docker adalah "mesin" di belakang layar. Perintah docker cuma klien; kalau mesinnya mati, ya nggak nyambung.

2. permission denied while trying to connect to the Docker socket

User-mu belum masuk grup docker.

sudo usermod -aG docker $USER
# lalu logout-login ulang, atau:
newgrp docker

3. 401 Unauthorized / Invalid API key

Key salah atau belum di-export. Cek ulang:

echo $OPENAI_API_KEY   # pastikan tidak kosong

Kenapa terjadi: environment variable hilang setiap buka terminal baru. Taruh di ~/.bashrc atau ~/.zshrc kalau mau permanen (tapi hati-hati soal keamanan).

4. Tugas timeout atau ke-kill karena kehabisan memori (OOM)

Ini justru salah satu hal yang dibenahi di 2.1. Kalau masih kena, kemungkinan mesinmu memang kurang bertenaga.

• Kurangi paralelisme (jumlah container bersamaan).

• Pindah ke sandbox cloud dengan sumber daya lebih besar.

5. executable not found in $PATH

Menurut analisis error resmi, kegagalan paling sering justru karena agent memanggil program yang belum terpasang atau tidak ada di PATH. Kalau ini muncul di tugas buatanmu sendiri, pastikan Dockerfile sudah memasang semua tool yang dibutuhkan (contoh nyata: menambahkan procps supaya tooling background-process jalan).

6. Hasil beda-beda tiap run

Non-determinisme itu wajar (hardware, API eksternal). Solusinya: naikkan --n-attempts dan laporkan rata-rata plus confidence interval.

Review Jujur: Kelebihan dan Kekurangan

Biar seimbang, ini penilaian apa adanya.

Kelebihan:

• Realistis. Tugasnya benar-benar mirip kerjaan engineer, bukan soal mainan.

• Beragam. Dari software engineering, sysadmin, data, training model, sampai keamanan.

• Transparan & open-source. Dataset, harness, sampai rincian perbaikan dipublikasikan.

• Adil. Adanya Terminus 2 sebagai harness netral membantu perbandingan antar-model.

• Terawat. Munculnya 2.1 membuktikan komitmen menjaga kualitas.

Kekurangan / keterbatasan:

Baca juga Kiro Dev: IDE Agentic AWS untuk Spec-Driven Development

• Risiko kontaminasi data. Karena publik, ada kemungkinan model dilatih di atas tugasnya. Canary string cuma pengaman simbolis.

• Non-determinisme. Hasil bisa bergeser karena hardware atau API eksternal.

• Butuh sumber daya. Sebagian tugas berat; nggak ramah buat mesin pas-pasan.

• Angka leaderboard membingungkan. Beda harness dan beda sumber bikin perbandingan mudah menyesatkan kalau nggak hati-hati.

Cocok untuk siapa:

• Peneliti AI dan tim yang bikin agent, yang butuh ukuran kemampuan terminal yang serius.

• Perusahaan yang mau memilih model/agent untuk alur kerja CLI dan peduli pada rasio hasil-versus-biaya.

Sebaiknya dihindari (untuk saat ini) oleh:

• Yang cuma butuh cek "bisa nulis fungsi sederhana nggak" — itu terlalu berat, pakai benchmark yang lebih ringan.

• Yang tidak punya akses ke sumber daya komputasi memadai dan nggak mau pakai sandbox cloud.

Kenapa Ini Penting buat Strategi Tim (Sudut Pandang Praktis)

Kalau Teman-Teman memimpin tim engineering, relevansi Terminal-Bench 2.1 cukup langsung. Agent yang jago di terminal berarti berpotensi mengotomasi pekerjaan yang selama ini makan waktu: setup lingkungan, benerin build, konfigurasi, sampai tugas berulang lainnya.

Nilai bisnisnya ada pada efisiensi dan pengurangan kerja manual yang membosankan. Tapi keputusan adopsi sebaiknya berbasis data yang apel-ke-apel: uji model kandidat di harness yang sama, pada tugas yang mirip alur kerja tim, lalu timbang skor, biaya, dan waktu bersamaan. Benchmark ini alat bantu keputusan, bukan vonis akhir.

Untuk konteks lokal — misalnya tim di Indonesia yang sering kerja dengan jaringan dan sumber daya cloud yang bervariasi — dua catatan tadi jadi makin relevan: antisipasi non-determinisme dan siapkan sandbox cloud kalau infrastruktur lokal terbatas. Menjalankan evaluasi berat di laptop kantor biasa sering berujung timeout, dan itu menyesatkan hasilnya.

Pertanyaan yang Sering Muncul

Apakah 2.1 menggantikan 2.0? Untuk sebagian besar keperluan, iya, 2.1 lebih disarankan karena lebih bersih. Tapi skor 2.0 dan 2.1 tidak bisa dibandingkan langsung karena tingkat kesulitannya berbeda.

Apakah aku harus pakai Terminus 2? Kalau tujuanmu membandingkan model secara adil, iya. Kalau ingin tahu performa produk agent tertentu, pakai harness bawaannya.

Berapa lama menjalankan seluruh benchmark? Tergantung model dan sumber daya. Mayoritas tugas selesai di bawah 20 menit, tapi kasus ekstrem bisa sampai dua jam.

Di mana melihat skor terbaru? Langsung ke leaderboard resmi tbench.ai atau evaluasi independen, dan perhatikan harness serta metodologinya.

Kalau Teman-Teman mau baca sumber aslinya, tiga rujukan yang kredibel: pengumuman resmi rilis 2.1 di tbench.ai, makalah teknis di arXiv, dan penjelasan umum soal container di Docker.

Aku sengaja berhenti di sini dan tidak menulis kesimpulan/penutup, sesuai permintaan. Kalau ada bagian yang mau kamu perdalam (misalnya contoh Dockerfile satu tugas, atau langkah bikin tugas sendiri), tinggal bilang, nanti kita bahas lebih detail. 🙂

Membedah Anatomi Satu Tugas: Biar Nggak Cuma Teori

Sampai sini kita sudah ngobrol banyak soal konsep. Sekarang mari kita bongkar satu tugas Terminal-Bench dari dalam, supaya Teman-Teman punya gambaran konkret soal "isi perutnya". Ini penting, karena banyak orang membayangkan benchmark itu seperti kotak hitam yang misterius. Padahal begitu dibuka, strukturnya justru rapi dan masuk akal.

Setiap tugas di Terminal-Bench pada dasarnya adalah sebuah folder berisi beberapa berkas kunci. Ada berkas instruksi, ada Dockerfile untuk membangun lingkungan awal, ada skrip tes untuk verifikasi, dan ada solusi acuan. Kalau digambarkan, susunannya kurang lebih begini:

tasks/
└── configure-git-webserver/
    ├── task.yaml          # metadata + instruksi natural language
    ├── Dockerfile         # lingkungan awal container
    ├── solution.sh        # solusi acuan (oracle)
    └── tests/
        └── test_outputs.py  # skrip verifikasi hasil akhir

Coba perhatikan pemisahan tugasnya. Berkas task.yaml menyimpan deskripsi yang akan dibaca agent, misalnya "Siapkan git server bare, lalu konfigurasikan hook supaya setiap push otomatis men-deploy isi repo ke web server yang melayani di port 8080." Agent cuma membaca instruksi ini — dia tidak boleh mengintip skrip tes maupun solusi acuan. Adil, kan? Sama seperti murid yang tidak boleh melihat kunci jawaban sebelum ujian selesai.

Dockerfile: Panggung Tempat Agent Beraksi

Dockerfile-lah yang menentukan seperti apa "dunia" yang dihadapi agent saat pertama kali masuk. Contoh sederhananya begini:

FROM ubuntu:22.04

# Pasang tool dasar yang dibutuhkan tugas
RUN apt-get update && apt-get install -y \
    git \
    curl \
    python3 \
    procps \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /workspace

# Salin berkas awal yang relevan dengan tugas
COPY setup/ /workspace/

CMD ["/bin/bash"]

Kelihatan biasa saja, tapi di sinilah letak salah satu pelajaran paling penting dari revisi 2.1. Ingat masalah executable not found in $PATH yang tadi kita singgung di bagian troubleshooting? Nah, akar masalahnya sering ada di sini. Kalau tugas mengharuskan agent memeriksa proses yang berjalan di latar belakang tapi Dockerfile-nya lupa memasang procps (yang menyediakan perintah seperti ps), agent bakal buntu bukan karena bodoh, tapi karena panggungnya memang kurang lengkap. Detail sekecil satu paket bisa bikin skor sebuah tugas anjlok tanpa alasan yang adil.

Makanya, salah satu prinsip yang aku pegang saat membaca hasil benchmark adalah: selalu curigai lingkungan sebelum menyalahkan modelnya. Bukan berarti model selalu benar, tapi lingkungan yang bocor itu jauh lebih sering terjadi daripada yang orang kira.

Skrip Tes: Hakim yang Nggak Bisa Disuap

Bagian paling menentukan dari sebuah tugas adalah skrip tesnya. Inilah "hakim" yang memutuskan agent lulus atau tidak. Yang penting dipahami: tes ini memeriksa kondisi akhir, bukan proses. Contohnya untuk tugas git server tadi:

import subprocess
import urllib.request

def test_push_triggers_deploy():
    # Simulasikan sebuah push ke repo
    subprocess.run(
        ["git", "push", "origin", "main"],
        cwd="/workspace/local-clone",
        check=True,
    )

    # Verifikasi: apakah web server benar-benar menyajikan konten baru?
    response = urllib.request.urlopen("http://localhost:8080")
    body = response.read().decode()

    assert "deploy berhasil" in body, "Konten belum ter-deploy ke web server"
    assert response.status == 200, "Web server tidak merespons dengan benar"

Perhatikan bahwa tes ini sama sekali tidak peduli cara agent menyiapkan hook-nya. Mau pakai post-receive hook, mau pakai skrip cron, mau pakai cara nyeleneh sekalipun — selama hasil akhirnya web server benar-benar menyajikan konten yang benar di port 8080, agent dinyatakan lulus. Inilah roh dari benchmark yang berorientasi hasil. Kebebasan cara ini justru bikin ujiannya realistis, karena di dunia nyata pun tidak ada satu jalan tunggal untuk menyelesaikan masalah.

Sekarang bayangkan kalau tesnya salah tulis, misalnya mengharapkan konten di port 8000 padahal instruksinya bilang 8080. Agent yang benar-benar mengikuti instruksi malah dinyatakan gagal. Itulah tipe "salah spesifikasi" yang dibereskan di 2.1, persis seperti kasus query-optimize yang tadi kita bahas. Dari sini kelihatan kenapa tim rela menghabiskan rata-rata sekitar tiga jam per tugas hanya untuk audit. Satu ketidakcocokan kecil antara instruksi dan tes bisa merusak validitas seluruh skor.

Baca juga Codex CLI dari OpenAI: Panduan Lengkap Ngoding di Terminal

Cara Membuat Tugas Sendiri (Dan Kenapa Itu Sepadan)

Salah satu hal yang bikin Terminal-Bench beda dari benchmark tertutup adalah sifatnya yang terbuka untuk kontribusi. Kalau Teman-Teman punya kasus nyata yang menantang di kerjaan sehari-hari, kasus itu bisa jadi kandidat tugas yang bagus. Dan jujur saja, proses bikin tugas sendiri itu latihan berpikir yang lumayan mahal tapi berfaedah — karena memaksa kita mendefinisikan "sukses" secara sangat tegas.

Kerangka langkahnya kurang lebih begini:

Step 1 — Tentukan Tugas yang Punya "Jawaban Pasti"

Kunci pertama: tugasnya harus punya kondisi akhir yang bisa diverifikasi secara objektif. "Bikin website yang bagus" itu tugas buruk untuk benchmark, karena "bagus" itu subjektif. Sebaliknya, "bikin endpoint /health yang mengembalikan status 200 dengan body JSON {"status": "ok"}" itu tugas yang bagus, karena benar-salahnya jelas.

Pertanyaan penyaring yang aku suka pakai: "Bisakah aku menulis skrip yang secara otomatis memutuskan tugas ini lulus atau gagal, tanpa perlu penilaian manusia?" Kalau jawabannya tidak, tugasnya belum matang untuk dijadikan benchmark.

Step 2 — Tulis Solusi Acuan Lebih Dulu

Ini agak kontra-intuitif, tapi tim Terminal-Bench menekankan pentingnya solusi acuan (oracle). Sebelum melepas agent, kita harus membuktikan sendiri bahwa tugas itu memang bisa diselesaikan oleh manusia di dalam lingkungan yang sudah disiapkan. Kalau kita sendiri saja tidak bisa menyelesaikannya, jangan harap agent bisa — dan yang lebih penting, kita jadi tahu tugasnya memang wajar, bukan jebakan yang mustahil.

#!/bin/bash
# solution.sh — bukti bahwa tugas ini bisa diselesaikan

set -e  # berhenti kalau ada perintah yang gagal

# Langkah-langkah manual yang menyelesaikan tugas
git init --bare /srv/git/app.git
cat > /srv/git/app.git/hooks/post-receive <<'EOF'
#!/bin/bash
GIT_WORK_TREE=/var/www/html git checkout -f main
EOF
chmod +x /srv/git/app.git/hooks/post-receive

# Nyalakan web server sederhana
cd /var/www/html && python3 -m http.server 8080 &

Solusi acuan ini bukan cuma dokumentasi. Dia juga dipakai sebagai sanity check: kalau solusi acuan dijalankan lalu skrip tes tetap gagal, berarti ada yang salah di tes atau lingkungannya, bukan di agent. Ini semacam kalibrasi sebelum benchmark dipakai serius.

Step 3 — Uji Ketahanannya dengan Beberapa Model

Sebelum sebuah tugas layak masuk koleksi, dia perlu diuji lintas beberapa pasangan agent-model. Tujuannya bukan mencari yang paling gampang, tapi memastikan tingkat kesulitannya masuk akal dan tidak ada celah aneh. Kalau semua model kuat lulus dengan mudah, tugasnya mungkin terlalu ringan. Kalau semua gagal dengan pola error yang identik, hampir pasti ada bug di tugas itu, bukan di modelnya. Prinsip diagnosis ini sudah kita bahas, dan di sinilah dia berguna secara praktik.

Buat Teman-Teman yang mau serius berkontribusi, repositori resminya bisa ditelusuri lewat halaman komunitasnya di GitHub, tempat dokumentasi format tugas dan panduan kontribusi biasanya diperbarui. Membaca beberapa tugas yang sudah ada di sana adalah cara belajar tercepat sebelum bikin sendiri.

Mengenal Ragam Domain Tugas

Salah satu kekuatan Terminal-Bench yang sering luput dibahas adalah luasnya cakupan domain. Ini bukan benchmark yang cuma menguji satu jenis keahlian. Kalau dikelompokkan, tugas-tugasnya menyentuh banyak wilayah kerja teknis yang beda-beda karakternya.

Keragaman ini penting karena mencerminkan kenyataan: seorang engineer yang jago itu jarang cuma menguasai satu hal. Model yang cuma jago nulis kode Python tapi buntu begitu disuruh benerin PATH atau baca log systemd bukanlah asisten yang bisa diandalkan untuk kerja terminal sungguhan. Terminal-Bench sengaja menguji keluasan ini, bukan cuma kedalaman di satu titik.

Buat Teman-Teman yang memimpin tim, keragaman domain ini juga jadi sinyal berharga. Kalau tim kalian lebih banyak ngurusin infrastruktur ketimbang machine learning, perhatikan skor model di kategori sysadmin dan build, bukan cuma skor total. Skor rata-rata gabungan kadang menyesatkan, karena bisa jadi sebuah model tinggi di software engineering tapi payah di tugas yang justru relevan buat kalian.

Menyelami Cara Kerja Terminus 2

Kita sudah menyinggung Terminus 2 sebagai harness netral. Sekarang mari sedikit menyelam ke cara kerjanya, karena memahami ini membantu Teman-Teman membaca hasil dengan lebih bijak.

Terminus 2 sengaja dibuat sesederhana mungkin. Filosofinya: kalau kita mau membandingkan otak (model), jangan sampai perbandingannya tercemar oleh perbedaan tangan (perkakas). Maka Terminus 2 cuma memberi agent satu alat: sebuah terminal Bash tanpa antarmuka grafis. Semua tindakan agent — memasang paket, mengedit berkas, menjalankan tes — harus lewat perintah teks.

Alur kerjanya berputar dalam sebuah siklus sederhana:

1. Agent membaca instruksi tugas.

2. Agent memutuskan perintah Bash apa yang mau dijalankan.

3. Perintah dieksekusi di dalam container.

4. Output (termasuk error) dikembalikan ke agent sebagai konteks.

5. Agent membaca hasilnya, lalu memutuskan langkah berikutnya.

6. Siklus berulang sampai agent merasa selesai atau kehabisan anggaran.

Kelihatan sederhana, tapi justru di sinilah kemampuan sejati sebuah model diuji. Model yang bagus tidak cuma tahu perintah yang benar; dia juga tahu cara membaca error dan menyesuaikan strategi. Misalnya, saat sebuah pip install gagal karena versi Python tidak cocok, model yang cerdas akan menyimpulkan sendiri bahwa dia perlu ganti versi atau pakai virtual environment, tanpa disuruh. Model yang kurang matang akan mengulang perintah yang sama berkali-kali sambil berharap hasilnya beda — perilaku yang, jujur saja, kadang mirip kita waktu lagi frustrasi.

Kenapa netralitas harness itu krusial? Karena harness bawaan vendor sering di-tuning khusus untuk modelnya sendiri. Sebuah model bisa terlihat superior di harness-nya sendiri, lalu skornya menyusut begitu dibaca di Terminus 2 yang tidak memihak. Ada catatan bahwa peringkat model bahkan bisa terbalik begitu semuanya diukur di harness yang sama. Jadi kalau Teman-Teman lihat dua angka yang beda jauh untuk model yang sama, langkah pertama bukan bingung, tapi cek dulu: harness-nya sama nggak?

Menjalankan di Cloud Sandbox: Solusi Buat yang Mesinnya Pas-pasan

Tadi sempat disinggung soal sandbox cloud. Sekarang kita bahas lebih detail, karena ini sering jadi penyelamat, apalagi buat Teman-Teman di Indonesia yang mungkin kerja dengan laptop kantor standar atau koneksi yang naik-turun.

Masalahnya begini: sebagian tugas Terminal-Bench itu berat. Kompilasi kernel Linux, misalnya, bisa makan waktu lama dan menguras CPU. Training model, walaupun kecil, tetap butuh memori yang lumayan. Kalau Teman-Teman coba jalanin di laptop 8 GB RAM sambil buka belasan tab browser, ya wajar kalau container-nya kena OOM (kehabisan memori) lalu dibunuh paksa oleh sistem. Dan seperti sudah dibahas, hasil yang timeout itu menyesatkan — bikin model kelihatan gagal padahal masalahnya di mesin kita.

Solusinya: pindahkan eksekusi ke sandbox cloud. Tim resmi sendiri memakai penyedia seperti Daytona dan e2b untuk menjalankan evaluasi dalam skala besar. Keuntungannya:

• Sumber daya bisa diatur. Butuh RAM lebih besar untuk tugas berat? Tinggal naikin, tanpa harus beli laptop baru.

• Isolasi lebih bersih. Setiap run dapat lingkungan segar, jadi tidak ada sisa dari run sebelumnya yang mencemari hasil.

• Paralelisme aman. Mau jalanin banyak tugas sekaligus? Cloud lebih sanggup ketimbang satu mesin lokal.

Pola pemakaiannya biasanya mengarahkan Harbor untuk mengeksekusi container di penyedia sandbox alih-alih di Docker lokal. Detail persisnya berubah seiring pembaruan, jadi selalu cek dokumentasi terbaru. Tapi konsepnya tetap: pisahkan otak (model lewat API) dari otot (eksekusi container di cloud). Dengan begitu, laptop Teman-Teman cuma jadi pengendali, bukan tempat kerja berat sesungguhnya.

Satu catatan biaya yang jujur: sandbox cloud itu tidak gratis, dan menjalankan seluruh 89 tugas beberapa kali ulang bisa menumpuk tagihan — belum termasuk biaya token model. Jadi kalau tujuannya cuma mencoba-coba, mulai dari beberapa tugas dulu, bukan langsung hajar semua. Kalau tujuannya keputusan bisnis serius, hitung anggarannya di awal supaya tidak kaget di akhir bulan.

Baca juga CodeBuddy: Editor Kode AI untuk Coding Lebih Cepat

Membaca Trajektori: Harta Karun yang Sering Diabaikan

Kebanyakan orang cuma melirik angka skor akhir lalu selesai. Padahal, bagian paling berharga dari sebuah run justru ada di trajektori — rekaman lengkap setiap langkah yang diambil agent. Ini seperti rekaman CCTV dari seluruh proses berpikir dan bertindaknya si agent.

Kenapa trajektori berharga? Karena di situlah Teman-Teman bisa melihat bagaimana sebuah tugas gagal, bukan cuma bahwa dia gagal. Beberapa pola yang sering muncul saat membaca trajektori:

• Agent nyasar sejak awal. Dia salah paham instruksi di langkah pertama, lalu semua langkah berikutnya ikut salah arah. Ini sering menandakan instruksi tugas yang ambigu.

• Agent hampir berhasil tapi tersandung di akhir. Misalnya sudah benar semua, tapi lupa merestart service sehingga perubahannya belum aktif. Ini menandakan kelemahan model dalam hal ketelitian, bukan pemahaman.

• Agent terjebak dalam lingkaran. Mengulang perintah yang sama berkali-kali. Ini sinyal model kurang mampu belajar dari umpan balik error.

• Agent boros. Menyelesaikan tugas tapi dengan jumlah langkah dan token yang jauh lebih banyak dari perlu. Skornya lulus, tapi efisiensinya jelek.

Membaca trajektori inilah yang membedakan analisis benchmark yang dangkal dari yang serius. Kalau Teman-Teman sedang memilih model untuk tim, jangan cuma tanya "berapa skornya?" tapi juga "kalau gagal, gagalnya kayak apa?". Model yang gagal dengan cara yang "hampir benar" biasanya lebih bisa diandalkan di dunia nyata ketimbang model yang gagal total dengan cara yang tidak terduga, walaupun skor angkanya mirip.

Tim Terminal-Bench sendiri, seperti tadi disinggung, memakai alat debug berbasis LLM untuk menyisir trajektori dalam jumlah besar dan memilah mana kegagalan karena tugas dan mana karena keterbatasan model. Teman-Teman tidak harus secanggih itu — membaca beberapa trajektori secara manual saja sudah membuka banyak wawasan.

Membandingkan dengan Benchmark Lain

Terminal-Bench tidak hidup sendirian. Ada beberapa benchmark coding lain yang populer, dan memahami posisinya membantu Teman-Teman memilih alat ukur yang tepat.

Perbedaan filosofisnya menarik. HumanEval itu seperti ujian menulis satu paragraf: berguna untuk mengukur kemampuan dasar, tapi tidak memberitahu apakah seseorang bisa menulis buku utuh. SWE-bench selangkah lebih realistis karena berurusan dengan repositori sungguhan, tapi masih terpusat pada aktivitas mengedit kode. Terminal-Bench mengambil sudut yang lebih luas: ia peduli pada seluruh pekerjaan seorang engineer di terminal, dari memasang tool sampai membenahi lingkungan yang berantakan.

Tidak ada yang "paling benar" di antara ketiganya. Mereka mengukur hal yang berbeda. Kalau Teman-Teman mau tahu kemampuan model menulis algoritma murni, HumanEval masuk akal. Kalau mau tahu kemampuan menambal bug di proyek nyata, SWE-bench relevan. Kalau mau tahu apakah sebuah agent bisa jadi "asisten sysadmin dan engineer serba bisa" di terminal, di situlah Terminal-Bench bersinar. Bagi kebanyakan tim yang ingin mengotomasi kerja operasional, sudut pandang terminal ini justru yang paling dekat dengan kebutuhan sehari-hari.

Praktik Keamanan yang Wajib Diperhatikan

Ada satu hal yang sering dilupakan orang saat asyik menjalankan agent: Teman-Teman sedang memberi sebuah AI akses untuk mengeksekusi perintah sungguhan. Di dalam container yang terisolasi, ini relatif aman. Tapi begitu keluar dari konteks benchmark dan mulai memakai agent untuk kerja nyata, urusan keamanan jadi serius.

Beberapa prinsip yang sebaiknya dipegang:

• Selalu jalankan di lingkungan terisolasi. Jangan pernah kasih agent akses langsung ke mesin produksi atau ke shell dengan hak akses penuh tanpa pengaman. Container atau sandbox itu bukan formalitas, melainkan tembok pelindung.

• Jaga rahasia tetap rahasia. Ingat kembali soal API key: jangan pernah hardcode di berkas, jangan pernah commit ke git. Pakai environment variable atau pengelola rahasia. Kebocoran satu key bisa berujung tagihan bengkak atau, lebih buruk, akses yang disalahgunakan.

• Batasi cakupan izin. Kalau agent cuma perlu membaca sebuah folder, jangan kasih izin tulis ke seluruh sistem. Prinsip least privilege — beri hak seminimal yang dibutuhkan — berlaku juga di sini.

• Waspadai perintah destruktif. Sebuah agent yang salah paham bisa saja menjalankan perintah yang menghapus data. Di lingkungan uji ini tidak masalah karena container-nya sekali pakai, tapi di luar itu, pikirkan pengaman seperti konfirmasi manual untuk aksi berisiko.

Konteks benchmark memang membuat kita agak lupa soal ini, karena semuanya berjalan di dunia container yang aman dan sekali buang. Tapi begitu wawasan dari Terminal-Bench dipakai untuk memilih agent yang bakal dipasang di alur kerja nyata, kebiasaan keamanan yang baik harus ikut terbawa. Untuk pemahaman mendalam soal isolasi container dan model keamanannya, dokumentasi resmi dari Docker cukup lengkap dan layak dibaca sebelum Teman-Teman melangkah lebih jauh.

Analisis Biaya dan Token: Sisi yang Sering Dilupakan

Kita sudah menyinggung bahwa skor bukan segalanya. Sekarang mari kita perdalam soal biaya, karena inilah faktor yang sering menentukan keputusan di dunia nyata, bukan angka skor yang bikin bangga di presentasi.

Bayangkan skenario ini. Ada dua model. Model A mencetak resolution rate 60%, tapi rakus token dan lambat. Model B mencetak 55%, tapi hemat token dan cepat. Sekilas Model A menang. Tapi coba hitung ongkos sebenarnya: kalau untuk mencapai 60% itu Model A butuh biaya dua kali lipat dan waktu dua kali lebih lama, apakah selisih 5% itu sepadan? Untuk banyak kasus bisnis, jawabannya tidak.

Beberapa dimensi biaya yang perlu ditimbang bersamaan:

• Biaya token per tugas. Model yang bertele-tele (banyak langkah, banyak konteks) akan membakar lebih banyak token. Di beberapa tugas ekstrem, konsumsi token bahkan bisa menyentuh angka yang bikin geleng-geleng kepala — sudah disinggung soal tugas yang menghabiskan hampir 100 juta token.

• Waktu per tugas. Waktu itu uang, apalagi kalau agent dipakai dalam volume besar. Model yang menyelesaikan tugas dalam lima menit jelas lebih ekonomis dari yang butuh setengah jam untuk hasil serupa.

• Tingkat pengulangan. Kalau sebuah model sering gagal di percobaan pertama dan baru berhasil setelah beberapa kali coba, biaya efektifnya jauh lebih tinggi dari yang terlihat di skor pass@1.

Rumus mental yang aku sarankan: jangan pernah lihat skor tanpa melihat biaya di sebelahnya. Sebuah tabel keputusan yang sehat kira-kira seperti ini:

Angka di tabel ini sengaja aku buat kualitatif, bukan spesifik, karena — seperti sudah aku tegaskan berkali-kali — angka pasti dari berbagai sumber saling bertentangan dan gampang menyesatkan. Yang bisa dipegang adalah kerangka berpikirnya: timbang skor, biaya, dan waktu sebagai satu kesatuan. Keputusan yang cuma berdasar satu angka biasanya keputusan yang bakal disesali.

Menjalankan Model Open-Weight: Bukan Cuma Milik Vendor Besar

Satu hal yang menyenangkan dari ekosistem ini adalah Teman-Teman tidak terkurung pada model dari vendor besar saja. Model open-weight — model yang bobotnya bisa diunduh dan dijalankan sendiri — juga bisa diuji di Terminal-Bench, dan ini membuka banyak kemungkinan menarik.

Kenapa ini penting? Beberapa alasan praktis:

• Kendali penuh. Dengan model open-weight, Teman-Teman bisa menjalankannya di infrastruktur sendiri, tanpa mengirim data ke pihak ketiga. Untuk perusahaan yang sensitif soal privasi data, ini nilai jual besar.

• Biaya bisa lebih terkendali. Alih-alih membayar per token ke API, Teman-Teman bisa menyewa GPU dan menjalankannya sendiri, yang untuk volume tertentu bisa lebih hemat.

• Bebas oprek. Model terbuka bisa di-tuning atau disesuaikan untuk kebutuhan spesifik, sesuatu yang tidak mungkin dilakukan pada model tertutup.

Untuk mengujinya, biasanya Teman-Teman mengarahkan harness ke penyedia yang melayani model open-weight lewat API yang kompatibel, misalnya lewat layanan seperti Together AI, atau bahkan ke server lokal yang menjalankan model sendiri. Pola perintahnya mirip yang tadi, tinggal ganti model dan konfigurasi endpoint-nya:

export TOGETHER_API_KEY="..."

harbor run -d [email protected] \
  --agent terminus-2 \
  --model "meta-llama/some-open-model" \
  --n-attempts 3

Ekspektasi yang jujur: model open-weight, terutama yang berukuran lebih kecil, umumnya masih tertinggal dari model frontier terbaik di tugas terminal yang berat. Ingat data yang cukup kredibel tadi — di Terminal-Bench 2.0, model kecil ada di kisaran belasan persen sementara frontier terbaik masih di bawah 65%. Jadi jangan berharap keajaiban dari model mungil. Tapi untuk tugas-tugas yang lebih ringan dan terprediksi, model open-weight bisa jadi pilihan yang sangat masuk akal dari segi biaya dan kendali. Kuncinya, sekali lagi: uji sendiri di harness yang sama, pada tugas yang mirip kerjaan tim, lalu putuskan berdasar data, bukan hype.

Checklist Adopsi untuk Tim: Dari Penasaran ke Keputusan

Buat Teman-Teman yang memimpin tim dan sedang serius mempertimbangkan mengadopsi agent terminal, aku susun sebuah checklist praktis. Ini bukan aturan kaku, tapi urutan berpikir yang membantu supaya keputusan tidak asal ikut tren.

Baca juga GitHub Copilot: Cara Mempercepat Kerja Tim

• Definisikan alur kerja target dulu. Sebelum menguji apa pun, tuliskan tugas nyata yang paling ingin kalian otomasi. Setup lingkungan? Benerin build yang gagal? Konfigurasi rutin? Ini jadi tolok ukur relevansi.

• Bikin beberapa tugas turunan yang mirip kerjaan kalian. Skor benchmark umum itu petunjuk awal, tapi tugas yang mirip konteks kalian jauh lebih meyakinkan. Ingat pelajaran dari 2.1: kunci versi dependency-nya biar hasilnya reproducible.

• Pilih harness netral untuk perbandingan. Kalau tujuannya membandingkan beberapa model, pakai Terminus 2 supaya adil. Kalau tujuannya menilai satu produk agent tertentu, pakai harness bawaannya.

• Jalankan beberapa kali, jangan sekali. Non-determinisme itu nyata. Rata-ratakan minimal tiga kali dan perhatikan sebaran hasilnya, bukan cuma angka tunggal.

• Catat skor, biaya, dan waktu bersamaan. Jangan tergoda skor mentah. Rasio hasil-terhadap-biaya yang jadi penentu di dunia nyata.

• Baca trajektori tugas yang gagal. Pahami bagaimana model gagal, bukan cuma bahwa dia gagal. Ini memberi gambaran keandalan yang tidak terlihat di angka.

• Antisipasi infrastruktur. Kalau mesin lokal terbatas, siapkan sandbox cloud sejak awal. Menjalankan tugas berat di laptop kantor sering berujung timeout yang menyesatkan.

• Baca skor resmi dengan kritis. Sebelum mengambil kesimpulan dari angka orang lain, pastikan harness dan metodologinya sama. Buka leaderboard resmi, jangan telan angka dari sembarang situs.

Checklist ini mungkin terasa panjang, tapi percayalah, mengabaikannya justru lebih mahal. Banyak tim yang buru-buru mengadopsi agent karena skor benchmark yang mengesankan, lalu kecewa di lapangan karena ternyata skor itu diukur di kondisi yang jauh berbeda dari kebutuhan mereka. Sedikit kesabaran di tahap evaluasi menghemat banyak penyesalan di tahap produksi.

Kesalahpahaman yang Sering Terjadi

Ada beberapa mitos dan kesalahpahaman soal Terminal-Bench yang perlu diluruskan, karena kalau dibiarkan bisa menyesatkan cara Teman-Teman menafsirkan hasil.

"Skor tinggi berarti agent-nya siap dipakai produksi." Belum tentu. Benchmark mengukur kemampuan di tugas-tugas tertentu dalam kondisi terkendali. Kesiapan produksi melibatkan banyak faktor lain: keandalan jangka panjang, keamanan, integrasi dengan alat yang sudah ada, dan biaya operasional. Skor itu satu masukan, bukan vonis.

"Kalau model gagal, berarti modelnya jelek." Sudah kita bahas panjang lebar, tapi layak diulang karena penting: kegagalan bisa berasal dari tugas yang bermasalah, lingkungan yang bocor, atau sumber daya yang kurang. Justru inilah alasan lahirnya 2.1. Jangan buru-buru menyalahkan model.

"Angka dari situs mana pun bisa langsung dibandingkan." Ini jebakan paling umum. Beda harness, beda sumber, beda metodologi — semuanya bikin angka tidak apple-to-apple. Membandingkan skor Terminus 2 dengan skor dari harness vendor itu seperti membandingkan waktu lari di lintasan datar dengan waktu lari di tanjakan. Angkanya ada, tapi tidak setara.

"2.1 dan 2.0 bisa dibandingkan skornya langsung." Tidak bisa. Karena 28 tugas diperbaiki dan tingkat kesulitannya berubah, skor di 2.1 cenderung lebih tinggi bukan semata karena model membaik, tapi karena tugasnya jadi lebih bersih dan bisa dikerjakan. Membandingkan keduanya secara mentah bakal memberi kesimpulan yang keliru.

"Benchmark publik pasti bebas dari kecurangan." Justru karena publik, ada risiko kontaminasi data — kemungkinan model dilatih di atas tugas-tugas yang sama. Canary string yang dipasang di dataset itu pengaman simbolis, bukan jaminan mutlak. Maka bacalah skor yang sangat tinggi dengan sedikit skeptisisme sehat.

Membangun Kebiasaan Evaluasi yang Sehat di Tim

Terminal-Bench mengajarkan sesuatu yang lebih besar dari sekadar cara mengukur agent. Ia mengajarkan budaya evaluasi yang jujur. Dan budaya ini bisa dibawa ke praktik tim Teman-Teman, terlepas dari apakah kalian pakai benchmark ini atau tidak.

Prinsip pertama: ukur kondisi akhir, bukan proses. Saat menilai hasil kerja — entah dari agent maupun dari manusia — fokuslah pada apakah hasilnya benar, bukan apakah caranya sesuai selera kita. Ini melatih objektivitas dan mengurangi bias.

Prinsip kedua: saat sesuatu gagal berulang dengan pola yang sama, curigai sistemnya, bukan pelakunya. Ini pelajaran langsung dari kenapa 28 tugas harus diperbaiki. Di tim, ini berarti kalau banyak orang tersandung di proses yang sama, mungkin prosesnya yang perlu dibenahi, bukan orang-orangnya yang disalahkan.

Prinsip ketiga: rawat alat ukurmu. Benchmark yang baik bukan sekali jadi lalu ditinggal, dan 2.1 membuktikannya. Sama halnya, metrik dan proses di tim perlu ditinjau ulang secara berkala. Yang dulu relevan bisa jadi usang, dan mempertahankan ukuran yang sudah bocor cuma menghasilkan kesimpulan yang salah.

Prinsip keempat: transparansi membangun kepercayaan. Tim Terminal-Bench mempublikasikan rincian per-tugas soal apa yang mereka perbaiki. Keterbukaan seperti ini membuat orang lebih percaya pada hasilnya, karena semua bisa diperiksa. Di tim, transparansi soal bagaimana keputusan diambil dan bagaimana hasil diukur menumbuhkan kepercayaan yang sama.

Buat konteks lokal, budaya ini terasa makin relevan. Di banyak tim di Indonesia, keputusan teknis kadang diambil berdasar tren atau rekomendasi vendor tanpa pengujian yang benar-benar sesuai konteks. Terminal-Bench, dengan segala keterbatasannya, menawarkan contoh bagaimana evaluasi yang serius itu dilakukan: definisikan sukses secara tegas, uji berulang, timbang biaya, dan baca hasilnya dengan kepala dingin. Kebiasaan ini jauh lebih berharga daripada sekadar tahu satu angka skor.

Skenario Praktis: Menyusun Rencana Uji Coba Pertama

Supaya semua yang sudah kita bahas jadi lebih membumi, mari kita susun sebuah rencana uji coba pertama yang realistis. Anggap Teman-Teman baru mau mulai, dengan sumber daya terbatas, dan ingin hasil yang bermakna tanpa membakar terlalu banyak biaya.

Minggu pertama — siapkan fondasi. Fokus di prasyarat. Pastikan Docker berjalan mulus, Python siap, dan uv terpasang. Jalankan docker run hello-world sampai benar-benar sukses. Jangan lanjut sebelum langkah ini beres, karena mayoritas frustrasi berawal dari fondasi yang goyah. Siapkan juga API key dan simpan dengan aman lewat environment variable.

Minggu kedua — coba skala kecil. Jangan langsung jalanin 89 tugas. Pilih segelintir tugas dulu, idealnya yang paling dekat dengan alur kerja tim. Jalankan dengan Terminus 2 dan satu model yang sudah Teman-Teman kenal. Amati outputnya, baca trajektorinya, biasakan diri dengan cara Harbor melaporkan hasil. Ini fase belajar membaca, bukan fase menyimpulkan.

Minggu ketiga — bandingkan beberapa model. Setelah nyaman dengan alurnya, jalankan dua atau tiga model kandidat di tugas yang sama, dengan harness yang sama, minimal tiga kali ulang. Catat skor, biaya, dan waktu dalam satu tabel. Di sinilah kerangka berpikir "hasil versus biaya" mulai kepakai.

Minggu keempat — putuskan dan dokumentasikan. Berdasar data yang terkumpul, ambil kesimpulan sementara: model mana yang paling masuk akal untuk kebutuhan tim, dengan alasan yang jelas. Dokumentasikan metodologinya — harness apa, berapa kali ulang, tugas apa saja — supaya keputusan ini bisa diperiksa ulang dan diperbarui saat ada model baru.

Rencana empat minggu ini sengaja dibuat santai, bukan karena prosesnya lama, tapi karena buru-buru justru sering menghasilkan kesimpulan yang salah. Kalau Teman-Teman punya lebih banyak waktu dan sumber daya, tentu bisa dipercepat. Tapi urutannya tetap: fondasi dulu, baru skala kecil, baru perbandingan, baru keputusan. Melompati tahap awal biasanya berakhir dengan angka yang tidak bisa dipercaya.

Apa yang Bisa Kita Harapkan ke Depan

Terminal-Bench, seperti yang sudah kita lihat dari perjalanan 1.0 ke 2.0 ke 2.1, adalah benda hidup yang terus dirawat. Kemunculan validasi berkelanjutan (continuous validation) menandakan arah yang jelas: tim ingin masalah seperti dependency yang berubah atau spesifikasi yang tak sinkron ketahuan lebih awal, sebelum sempat mencemari skor banyak orang.

Baca juga Mengenal Astro 7.1: Framework JavaScript Ringan untuk Website

Beberapa arah yang masuk akal untuk diperhatikan ke depan:

• Cakupan domain yang makin luas. Seiring agent makin mampu, tugas-tugas baru yang lebih menantang kemungkinan besar akan ditambahkan untuk menjaga benchmark tetap relevan. Kalau semua model sudah mudah lulus, benchmark kehilangan gunanya sebagai pembeda.

• Perlawanan terhadap kontaminasi data. Karena risiko model dilatih di atas dataset publik itu nyata, tidak mengherankan kalau ke depan ada mekanisme yang lebih kuat dari sekadar canary string, misalnya set tugas privat yang dipakai untuk verifikasi.

• Standardisasi pelaporan. Kebingungan soal angka leaderboard yang beda-beda antar harness dan sumber itu masalah nyata. Dorongan ke arah pelaporan yang lebih seragam — harness yang sama, metodologi yang transparan — akan sangat membantu komunitas.

• Peran komunitas yang makin besar. Banyak perbaikan di 2.1 berasal dari laporan komunitas, dan sifat open-source-nya mengundang lebih banyak kontribusi. Semakin banyak mata yang memeriksa, semakin cepat celah ketahuan dan diperbaiki.

Buat Teman-Teman yang ingin terus mengikuti perkembangan, kebiasaan terbaik adalah rutin mengecek leaderboard resmi dan pengumuman resminya, bukan mengandalkan rangkuman pihak ketiga yang belum tentu akurat. Ekosistem ini bergerak cepat, dan yang benar hari ini bisa berubah dalam hitungan bulan. Sikap yang sehat adalah tetap ingin tahu, tapi juga tetap kritis — persis semangat yang membuat 2.1 lahir sebagai perbaikan atas 2.0.

Kesimpulan

Kalau ada satu benang merah dari seluruh pembahasan ini, itu adalah: angka tanpa metodologi cuma jadi hiasan. Terminal-Bench 2.1 lahir bukan karena versi sebelumnya gagal, tapi karena tim dan komunitasnya sadar bahwa benchmark yang bagus harus terus dirawat — dependency yang berubah, spesifikasi yang tak sinkron, sampai risiko kontaminasi data, semuanya harus dijaga supaya skor benar-benar mencerminkan kemampuan agent, bukan kebetulan. Perjalanan dari 1.0 ke 2.1, ditambah hadirnya validasi berkelanjutan, adalah bukti bahwa kredibilitas sebuah benchmark dibangun dari transparansi, bukan dari klaim.

Buat Teman-Teman yang mau memakai benchmark ini untuk keputusan nyata, rencana empat minggu tadi bukan sekadar formalitas. Fondasi dulu, baru skala kecil, baru perbandingan lintas model dengan harness yang sama dan pengulangan yang cukup, baru keputusan yang didokumentasikan. Urutan itu yang membedakan tim yang memilih model berdasar data dari tim yang cuma ikut-ikutan tren leaderboard. Kerangka "hasil versus biaya" akan jauh lebih berguna kalau datanya memang bisa dipertanggungjawabkan.

Terakhir, ingat bahwa ekosistem ini bergerak cepat — yang benar hari ini bisa usang dalam hitungan bulan. Maka kebiasaan paling sehat adalah tetap penasaran sekaligus kritis: rutin cek leaderboard dan pengumuman resmi, jangan telan mentah-mentah rangkuman pihak ketiga, dan jadikan hasil pengujianmu sendiri sebagai patokan akhir. Mulailah dari satu tugas, satu harness, dan tiga kali pengulangan minggu ini juga. Dari situ, biarkan datamu sendiri yang menuntun keputusanmu — karena pada akhirnya, benchmark terbaik adalah yang kamu pahami cara kerjanya.

Referensi

Terminal-Bench. (2026). Terminal-Bench 2.1.

Terminal-Bench. (2026). Terminal-Bench.

Artificial Analysis. (2026). Terminal-Bench v2.1 Benchmark Leaderboard.

CodingFleet. (2026). Terminal-Bench 2.1 Leaderboard: AI CLI Coding Ranked.

GitHub. (2026). harbor-framework/terminal-bench-2-1: Terminal-Bench 2.1.

Vals AI. (2026). Terminal-Bench 2.1.

arXiv. (2026). Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces.

LLM Boss. (2026). Terminal-Bench 2.1: Agentic Terminal Coding Benchmark.

GitHub. (2026). harbor-framework/terminal-bench: A Benchmark for LLMs on Terminal Tasks.

R&D World Online. (2026). Terminal-Bench 2.1 Model Scores.