mlsanityData to 7 Oct 2026

What Makes a Terminal-Bench Task Hard? Separating Genuine Hardness from Fake-Hardness on an Adjudicated Agentic Corpus

arXiv 2609.26826 ↗First posted 20 Sep 2026cs.LG cs.AIcited by 0

On the map: LLM agents and tool use → Software engineering coding agents also fits: Agent skill learning and evolution

Abstract (arXiv)

Frontier benchmarks need tasks that current models cannot solve. But a task that no model solves is not automatically a hard task. The same zero pass rate can come from a real capability gap, but it can also come from missing context, a broken reference solution, infrastructure failure, or a verifier that can be bypassed. In this paper, we study this issue using a frozen Terminal-Bench 3 / Frontier-Bench 0.1 production record with 1,081 pull requests, 639 scored tasks, 28,801 trials, and 105,933 in logged agent spend. We ask what an all-fail task actually certifies. For the 125 tasks with no honest pass, we combine task artifacts, reference-solution runs, empty-solution controls, adversarial trials, trajectories, telemetry, and review records, and apply an ordered validity screen. Only 78 of the 125 tasks survive as certified-unsolved candidates. The remaining tasks include 14 with broken oracles, 8 dominated by infrastructure failures, 4 that are only passable through verifier bypasses, and 21 whose solvability is not certified by the available evidence. Thus, lack of saturation and genuine difficulty are not the same thing. The certified-unsolved label is also narrow: it means that the authored route passed, infrastructure did not dominate, no strict bypass was observed, and all evaluated agents failed. It does not prove intrinsic hardness, verifier completeness, or failure at the intended capability. We further analyze rejected submissions and passing tasks to show that pass rate alone cannot explain why a task is difficult. Overall, our results suggest that frontier benchmarks should report the evidence behind their all-fail tasks before using them as capability claims.

Key facts. No citing papers in the map yet (data through 7 Oct 2026). Placed in Software engineering coding agents, one of 16 directions in LLM agents and tool use. Builds on 8 of its 9 references that are in the map. First posted on arXiv 20 Sep 2026.

Builds on

8 of 9 references.

Closest ancestors · 2

Same direction, newest first

  1. 2026Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering16 Jun
  2. 2025Does SWE-Bench-Verified Test Agent Ability or Model Memory?11 Dec

Other references · 6

  1. 2025Establishing Best Practices for Building Rigorous Agentic Benchmarkscited by 94
  2. 2026LLMs Gaming Verifiers: RLVR can Lead to Reward Hackingcited by 24
  3. 2026LLM-as-a-Verifier: A General-Purpose Verification Frameworkcited by 21
  4. 2026Do Androids Dream of Breaking the Game? Systematically Auditing AI Agent Benchmarks with BenchJackcited by 13
  5. 2026On the limits and opportunities of AI reviewers: Reviewing the reviews of Nature-family papers with 45 expert scientistscited by 6
  6. 2026Measuring Five-Nines Reliability: Sample-Efficient LLM Evaluation in Saturated Benchmarkscited by 1

Built on by

Not cited yet.

Similar, not cited

Close in wording, no citation either way

  1. 2026What Makes a Good Terminal-Agent Benchmark Task: A Guideline for Adversarial, Difficult, and Legible Evaluation Design
  2. 2026Maintaining Benchmarks Against Increasingly Capable Agents: Detection and Remediation of Unearned Passes
  3. 2026From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents
  4. 2026The Unreliable Progress Bar: Can LLM Agents Reliably Report Task Progress Throughout Execution?
  5. 2026What Stops a Small Language Model From Driving a Database Agent
  6. 2026Tmax: A simple recipe for terminal agents
  7. 2026Automated Benchmark Auditing for AI Agents and Large Language Models
  8. 2026Confident and Wrong: Silent Semantic Failures in Coding Agents