Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces

Meta info.

• Authors: Mike A. Merrill, Alexander G. Shaw, Nicholas Carlini, Boxuan Li, Harsh Raj, Ivan Bercovich, Lin Shi, Jeong Yeon Shin, Thomas Walshe, E. Kelly Buchanan, Junhong Shen, Guanghao Ye, Haowei Lin, Jason Poulos, Maoyu Wang, Marianna Nezhurina, Jenia Jitsev, Di Lu, Orfeas Menis Mastromichalakis, Zhiwei Xu, Zizhao Chen, Yue Liu, Robert Zhang, Leon Liangyu Chen, Anurag Kashyap, Jan-Lucas Uslu, Jeffrey Li, Jianbo Wu, Minghao Yan, Song Bian, Vedang Sharma, Ke Sun, Steven Dillmann, Akshay Anand, Andrew Lanpouthakoun, Bardia Koopah, Changran Hu, Etash Guha, Gabriel H. S. Dreiman, Jiacheng Zhu, Karl Krauth, Li Zhong, Niklas Muennighoff, Robert Amanfu, Shangyin Tan, Shreyas Pimpalgaonkar, Tushar Aggarwal, Xiangning Lin, Xin Lan, Xuandong Zhao, Yiqing Liang, Yuanli Wang, Zilong Wang, Changzhi Zhou, David Heineman, Hange Liu, Harsh Trivedi, John Yang, Junhong Lin, Manish Shetty, Michael Yang, Nabil Omi, Negin Raoof, Shanda Li, Terry Yue Zhuo, Wuwei Lin, Yiwei Dai, Yuxin Wang, Wenhao Chai, Shang Zhou, Dariush Wahdany, Ziyu She, Jiaming Hu, Zhikang Dong, Yuxuan Zhu, Sasha Cui, Ahson Saiyed, Arinbjörn Kolbeinsson, Jesse Hu, Christopher Michael Rytting, Ryan Marten, Yixin Wang, Alex Dimakis, Andy Konwinski, Ludwig Schmidt
• Affiliation: Stanford University; Laude Institute; Anthropic; Northeastern University; UC Santa Barbara; Cornell University; Snorkel AI; Reflection AI; CMU; MIT; Peking University; Constellation; JSC FZJ; Tencent AI; National Technical University of Athens; Nerion; University of Michigan; NUS; Moonshot AI; Amazon; UT Austin; University of Washington; UW-Madison; UC Berkeley; SambaNova Systems Inc.; Bespoke Labs; Michigan State University; Brown University; Boston University; University of California San Diego; Beijing Institute of Technology; Allen Institute for AI; Monash University; CSIRO's Data61; Dartmouth College; Princeton University; CISPA; University of Basel; Stony Brook University; UIUC; Yale University; University of Virginia
• Paper: https://arxiv.org/abs/2601.11868
• Code: https://www.tbench.ai/
• Published: January 17, 2026 (arXiv preprint); ICLR 2026

TL; DR

터미널의 최종 container 상태로 scoring하는 agent 벤치마크 Terminal-Bench 2.0 제안; 32,155 trial에서 최고 성능은 63%에 그치고, 실패의 지배 범주가 능력 부족이라기 보다는 지시 위반/반복/종료 판단 실패라는 execution 규율 문제임을 LLM judge 기반 taxonomy로 규명

Background

• agent 벤치마크 현황
  • software engineering: 대체로 “이 저장소의 이슈를 고쳤나” 수준의 좁은 단위
    • SWE-Bench (Jimenez et al., 2024)
    • SWE-Bench Multimodal (Yang et al., 2025b)
    • SWE-Lancer (Miserendino et al., 2025)
    • HumanEval, DevEval, …
  • tool use: 도구 호출 형식과 선택이 초점
    • τ-Bench (Yao et al., 2025)
    • BFCL (Patil et al., 2025)
  • computer use: GUI와 웹 조작
    • WebArena (Zhou et al., 2024)
    • VisualWebArena (Koh et al., 2024)
    • AppWorld (Trivedi et al., 2024)
    • OSWorld (Xie et al., 2024)
  • scientific discovery: 논문 재현, ML 실험 자동화
    • ReplicationBench (Ye et al., 2025)
    • MLGym-Bench (Nathani et al., 2025)
    • Auto-Bench (Chen et al., 2025)
• 터미널은 고숙련 task가 실제로 수행되는 공간이자 실사용 agent의 사실상 표준 인터페이스
  • SW 엔지니어링, 과학 계산, 보안, ML 등 수행
  • Cursor, Codex CLI, Claude Code, Gemini CLI가 이미 이 인터페이스를 사용
    • 연구적인 벤치마크로 뒤쳐졌다는 의미 같기도…
• 핵심 공백: 터미널 관련 벤치마크는 CLI의 좁은 면만 평가, terminal-based task 전반에 대한 평가 부재
  • shell script 최적화 (Koala, Lamprou et al., 2025)
  • 환경 설정 (EnvBench, Eliseeva et al., 2025)
  • 자연어에서 bash로의 번역 (Westenfelder et al., 2025) 정도

Problem States

• 기존 벤치마크 한계
  • 현실성 부족: 합성의 예쁘게 정의된 벤치마크 풀이와 실제 container에서의 레거시 시스템 설정, 논문 재구현 괴리
  • 변별력 부족: frontier 모델이 이미 포화시킨 벤치마크로는 모델 간 차이도 개선 방향도 관측 불가
• 구축 측면의 한계: 어려운 agentic task는 정답 검증 자체가 난제
  • 테스트가 느슨하면 대충 해도 통과, 빡빡하면 정당한 대안 풀이를 기각
  • agent가 테스트 파일 열람이나 예상 답 전량 생성 등으로 cheat 가능
    • 이래서 논문의 지면 배분이 데이터 구축보다 검증 프로세스에 실려 있는 듯

Suggestions

task formulation Fig 2

• Terminal-Bench task 1개 = instruction + Dockerfile + tests + oracle solution + time limit
  • agent에게 노출되는 것은 Dockerfile로 빌드된 container와 instruction 둘뿐
  • tests/, run-tests.sh, solution.sh, task.yaml의 나머지 필드는 은닉
    • tests/ : 채점 기준
    • run-tests.sh : 테스트 실행 스크립트
    • solution.sh : 정답
    • task.yaml 등 : time limit, 난이도, 카테고리, 저자 추정 소요시간 등 메타정보
• 실행 흐름: container 전달 → agent 자유 활동 → time limit 도달 시 강제 종료 → 이 시점에 tests를 container 안으로 복사 → 실행
  • 테스트가 실행 이후에 주입되므로 채점 기준 열람이 원천 차단
• outcome-driven scoring:
  • 채점 대상은 agent가 친 명령어나 console 출력이 아니라 최종 container 상태
    • “지시에 서술된 모든 결과가 달성됐는가”만 판정 → 방법은 무제한
      • python script 작성
      • vim 직접 편집
      • 패키지 신규 설치 등
    • 이 유연성 덕에 기존 벤치마크 26개를 동일 포맷으로 흡수(Appendix D Tab 5).
  • all-or-nothing; 전 테스트 통과 = 1, 하나라도 실패 = 0

dataset construction

• open-source 기여 방식의 crowd-sourcing
  • 93명이 229개 task 작성
  • 저자 난이도 판정과 3인 검수 > 89개 선별
• Fig 4 카테고리 분포
  • software engineering 26으로 최다
  • games, video processing, data quarrying, optimization, personal assistant 등 비엔지니어링 카테고리도 각 1 포함
• Tab 1 소요시간 추정 분포: 전문가 기준으로도 절반이 1시간 초과, 주니어 기준 대부분 하루 이상
  • e.g. fix-ocaml-gc : long-horizon task를 표현할 수 있음을 보이는 사례
    • 실패한 최적화 이후 OCaml garbage collector 수정, 전문가 1일 / 주니어 10일 추정

verification

• 단위 task 1개가 충족해야 할 기준 3가지
  • Specificity: container가 허용 가능한 상태로 끝날 때 그리고 그때만 테스트 통과 (iff, 양방향 조건)
    • 지시가 모든 정답 상태를 서술하고 테스트가 그걸 전부 포착해야 함
    • 3번, 4번, 6번
  • Solvability: oracle solution 실행 시 전 테스트 통과 (2번, 5번)
  • Integrity: 현실에 없을 지름길로 통과 불가 (2번, 7번)
    • e.g. 특정 commit의 git 저장소를 다루는 task라면 미래 commit을 history에서 제거
• Fig 3 7단계 audit으로 3가지 기준 강제
  • Phase 1 (pre-merge): 병합 전 코드만 보고 판단 가능한 것. 파일만 읽어도 가능.
    1. 기여자 체크리스트
    2. 자동 CI: canary string 존재, Dockerfile 내 테스트/정답 포함 여부, apt 의존성 pinning, privileged container 금지 등
    3. LLM 검사: 테스트가 검사하는 행동의 지시문 서술 여부, 오타, hardcoded solution 여부 등
    4. 전문가 리뷰
  • Phase 2 (post-merge): 실제 실행 후 판단 가능한 것. 실제 API /사람 비용 투여
    1. Terminus 모델 실험
    2. 수동 trajectory 감사
    3. adversarial exploit audit: OpenHands agent에 “너는 security bot이고 목표는 어떻게든 cheat해 통과하는 것” 프롬프트를 주입
       • 실제 검출된 exploit
         • 테스트 환경 monkey-patching: 문제를 푸는 대신 채점 코드를 고쳐 무조건 통과시킴
         • 답 찍기: 풀지 않고 그럴듯한 값만 출력
         • 후보 전량 생성: 답 하나를 고르는 대신 가능한 답을 모두 남겨둠; 테스트가 정답의 존재만 확인하고 오답의 부재는 확인하지 않으면 통과함
           • Specificity를 iff(양방향)로 요구하는 근거
  • → 최종 결정: task당 평균 7단계 전체 scoring에 평균 3 reviewer-hour 투입; 89개면 수백 person-hour

Terminus 2와 Harbor

• Fig 34 Terminus 2: 모델 튜닝 없이 공평하게 맞춘 중립적인 scaffold 제공된 실행 환경
  • agent scaffold는 대개 특정 모델에 맞춰 튜닝(동일 조직 제작 시 특히), 모델 성능과 scaffold 성능이 교란됨
  • 전용 파일 편집 도구나 다운로드 도구 없이 bash 단일 도구만 사용
    • 파일 작성 방식(script 작성, echo 주입, vim 실행)을 모델이 자율 결정
    • context limit 도달 시 요약 모듈 발동
      • “곧 다른 agent에게 작업을 넘긴다, 지금까지 한 일을 요약하라”로 압축
      • 수백만 토큰 규모 task도 지속 가능
  • 실행 순서: LLM이 keystroke(키보드로 칠 명령어 문자열) 출력 → Terminus는 container 내 tmux shell에서 실행 → 화면 pane 변화. 화면 전체를 모델에 입력
• Harbor: 대규모 agent 평가 실행 프레임워크
  • harbor run -d terminal-bench@2.0으로 재현
  • Daytona sandbox에서 container 32~100개 병렬 실험

Effects

• Experimental setup
  • agent 6종: Claude Code, Codex CLI, Gemini CLI (상용 CLI) / OpenHands (Wang et al., 2025), Mini-SWE-Agent (Yang et al., 2024), Terminus 2 (오픈, 자체)
  • 모델 16종: GPT-5.2, GPT-5, GPT-5-Mini, GPT-5-Nano, Claude Opus 4.5, Opus 4.1, Sonnet 4.5, Haiku 4.5, Gemini 3 Pro, 3 Flash, 2.5 Pro, 2.5 Flash, Grok 4, Grok Code Fast 1, GPT-OSS 120B/20B, Llama 4 Maverick, Qwen 3 Coder 480B, Kimi K2 Instruct, K2 Thinking, GLM 4.6, MiniMax M2
    • reasoning effort는 provider 기본값 (Anthropic, OpenAI는 medium)
    • open-weight는 Together.AI API 경유
  • 조합당 최소 5회 반복, 총 32,155 trial (1 trial = agent 1회의 task 1개 시도)
  • metric은 resolution rate(전 테스트 통과 비율)와 95% CI
• Results
  • Fig 1 Tab 2 Main
    • Codex CLI + GPT-5.2가 63%로 최고
    • Terminus 2 + Claude Opus 4.5가 58%, Terminus 2 + Gemini 3 Pro가 57%
    • 상위 13위까지 전부 proprietary 모델; open-weight 최고는 Terminus 2 + Kimi K2 Thinking의 36%
    • 소형 모델은 15% 내외, GPT-OSS-20B는 3% 수준
  • Finding 1: 모델 선택이 scaffold 선택보다 중요
    • 동일 Codex CLI에서 GPT-5-Nano를 GPT-5.2로 교체 시 +52%p
    • Gemini 2.5 Pro의 scaffold를 OpenHands에서 Terminus 2로 교체 시 +17%p
  • Finding 2 Fig 5, Fig 10: 전체 1회 실행 비용이 모델에 따라 $1~$100+로 분산
    • 대부분 trial은 20분 이내, model call 25회 미만, 토큰 1000만 미만
    • 극단적으로 2시간 동안 수백 회 호출하며 1억 토큰에 근접하는 사례 존재
  • Finding 3 Fig 6: 8개월간 SOTA 성능이 거의 2배
    • Gemini 2.5 Pro 2025-04 약 32%에서 GPT-5.2 2025-12 약 63%로 크게 상승
    • 저자도 1년 내 포화를 인정하고 신규 task set 지속 배포 계획을 명시
  • Finding 4 Fig 7: 사람이 느끼는 난이도와 모델이 느끼는 난이도가 괴리
    • empirical difficulty (새 개념): 사람 라벨(medium/hard)이 주관적이므로 Terminus 2에서 frontier 모델 평균 pass rate로 난이도를 재정의
      • 66.7% 이상 Easy, 33.3~66.7% Medium, 33.3% 미만 Hard
    • 양의 상관 존재 (r=0.436, p<0.001); human-hard의 93.3%가 empirically hard로 일치
    • 최대 괴리는 human-medium인데 모델에겐 hard인 54.5%; 인간 직관이 우위인 지점
      • e.g. break-filter-js-from-html(XSS 필터 우회), winning-avg-corewars(Redcode 전략)
      • 패턴 추종이 아니라 창의적, 적대적 추론을 요구
    • 역방향으로 human-medium 중 16.4%는 empirically easy; 대개 문서 준수 같은 절차적 하위 작업
  • Finding 5 (Fig 8): 실패의 대부분은 능력 부족이 아니라 execution 규율 문제
    • 풀어서가 아니라 지시를 어기거나, 같은 일을 반복하거나, 멈출 때를 몰라서 실패하더라
    • 실패 관측 절차:
      1. 분류 체계: 다중 agent용 분류인 MAST(Pan et al., 2025)를 단일 agent 환경에 맞게 정리해 Terminal Agent Taxonomy(TAT) 도출
         • 제외: “대화 리셋”, “정보 은닉”, “타 agent 출력 무시”는 단일 agent에 발생하지 않음
         • 병합: “task 명세 위반”과 “role 명세 위반”은 CLI에 역할 개념이 없어 구분 불가
         • “clarification 요청 실패”는 환경이 질문을 지원하지 않아 제외
      2. 판정 기준: 실패 mode마다 rubric 별도 작성
         • 구성은 framing(용어와 범위 고정) + decision procedure(단계별 MATCH/NO MATCH 분기) + 제외 기준
         • e.g. No or Irrelevant Verification은 “괜찮아 보인다” 류의 자기 주장을 검증으로 불인정; agent가 미완을 명시적으로 인정한 경우는 제외해 Premature Termination과 경계를 그음
      3. 판정과 검증:
         • LLM judge(GPT-5, high reasoning)
         • Docent로 로그를 훑어 rubric의 모호한 지점을 반복 정제
         • 캘리브레이션 20 trial에서 사람 주석자 간 일치 93%(Cohen’s κ)
         • human-labeled 120 trace 대비 judge 일치율 90%(precision 92%, recall 90%)
    • 측정 범위는 task마다 모델별 실패 trial 2개, scaffold는 Terminus 2로 고정
      • pytest 전수 채점과 무관한 사후분석; 점수에 영향을 주지 않고 실패 양상만 기술
      • Fig 8의 비율은 전수 통계가 아니라 표본 분포
    • 결과: Claude Opus 4.5와 GPT-5.2는 유사 프로파일로 Execution이 지배, coherence와 verification은 낮음; open-weight인 Qwen 3 Coder 480B는 전 범주에 고르게 높음
      • 저자 해석; execution에 몰린 모델은 지시 준수 강화로 대응 가능, 전 범주에 걸쳐 새는 모델은 일관성과 self-monitoring 메커니즘 자체가 필요

    계층	failure mode
    Execution	Disobey Specification / Step Repetition / Unaware of Termination Conditions
    Coherence	Reasoning-Action Mismatch / Context Loss / Task Derailment
    Verification	Premature Termination / No or Incorrect Verification / Weak Verification

  • Finding 6 Fig 9: command 단위 실패율은 모델별 9.2%(Grok 4)에서 26.7%(GPT-OSS-120B)
    • 판정에 별도 LLM judge 2개 사용
      • 실패 여부는 GPT-5(medium), 3인 다수결 66쌍 대비 92.4% 일치
      • taxonomy 분류는 GPT-5(high), 저자 1인 50개 주석 대비 82.0% 일치
    • 3,800건 균등 샘플의 분포
      • Invocation 35.1%; command not found 24.1%로 단일 최다, shell syntax error 4.5%
      • REPL 19.1%; module not found 8.3%, script syntax error 6.1%
      • Runtime 15.5%; app failure 9.6%
      • Filesystem 14.1%; file not found 11.1%
  • Finding 7 Fig 35 Fig 36: turn 수와 토큰 수는 성공률과 무관
    • episode 수와 성공률의 상관 r=-0.028 (p=0.916), 출력 토큰과 성공률의 상관 r=-0.170 (p=0.515)
    • GPT-5 Codex는 평균 10 episode로 44%, Claude Sonnet 4.5는 22 episode로 43%, GPT-5는 7 episode로 35%
    • 반대로 Qwen 3 Coder 480B와 GLM 4.5 Air는 35 episode를 쓰고 24%
    • GPT-5-Nano는 평균 6만 토큰으로 최다 출력이나 성공률 8%
      • 장황함은 꼼꼼함이 아니라 비효율적 추론의 신호
  • Fig 11 frontier tasks: task와 model 그리드에서 어떤 모델도 해결하지 못하는 군집이 존재
    • 복잡한 시스템 설정, 커널 드라이버 컴파일, DB 마이그레이션
    • 대각선 근처는 모델 능력 향상에 따라 unsolvable에서 solvable로 전이하는 후속 연구 대상

Personal note. 사용하고자하는 환경으로서는 재검토가 필요하다고 봅니다. 채점이 최종 container 상태 하나로 환원되고 부분점수가 없어서 중간에 무엇을 기록하든 점수에 반영되지 않고, clarification이 환경에서 지원되지 않아 taxonomy에서 아예 빠졌으므로 개입이나 확인 축을 보려면 재설계가 필요해보입니다. 세션 경계 부재는 이미 예상한 사항이나, 그와 별개로 write 여부를 조작한 조건이 일단 없긴 해서 “안 써서 나빠졌다”를 측정할 종속 변인도 실질적으로는 부재했기는 합니다.

그나마 조작 가능한 지점은 Terminus 2로 보이는데, context limit에서 발동해 하는 일은 외재화가 맞긴 하지만, 그 외재화된 정보의 수신처는 파일이 아니라 context이고, 요약 시 프롬프트는 진짜 요약해라 정도의 문장 수준인 것도 설계의 관심 밖에 있던 것으로 보여요. 조금 나이브하게 보면 뭘 쓰고 누가 볼 때에 따라 그 내용이 달라져야 하는지, 읽거나 쓰기는 어떻게 결정할지 정도는 변인으로 볼 수 있을 것 같기는 합니다.

버전이 문제인데… 논문은 2.0(2025-11)을 구구절절 설명했는데 현재는 4.0(2026-08)까지 나왔고, 3.0에서 task set이 크게 교체된 것으로 보여 논문의 63%와 현행 리더보드 수치는 비교가 불가할 것으로 보입니다. 4.0은 flat 8시간 timeout으로 측정 노이즈를 줄이고 8개를 제거, 19개를 수정했는데 2.0이 내세운 검증 절차가 3.0과 4.0에서도 유지됐는지는 문서로 확인되지 않습니다. 다만 8시간 timeout은 context 압축이 더 자주 발생한다는 뜻이라 요약 모듈 관측에는 오히려 유리할 수도? 비용문제측면도 좀 걸립니다.