Long-Horizon-Terminal-Bench: Testing the Limits of Agents on Long-Horizon Terminal Tasks with Dense Reward-Based Grading
Abstract: AI agents have become capable of autonomously completing short, well-specified tasks. However, existing terminal benchmarks largely focus on simple problems that finish within minutes and are evaluated only by their final outcome. This setup overlooks intermediate progress and partial solutions, yielding sparse reward signals and an incomplete picture of agent capability. We introduce Long-Horizon-Terminal-Bench, a terminal benchmark of 46 long-horizon tasks spanning nine categories, including experiment reproduction, software engineering, multimodal analysis, interactive games, and scientific computing. Each task follows a Terminal-Bench-style setup with a reference solution or simulation engine, but is further decomposed into fine-grained graded subtasks. This design enables dense intermediate rewards and partial credit, allowing evaluation to capture not only whether an agent reaches the final goal, but also how far it progresses on open-ended workflows. Tasks in Long-Horizon-Terminal-Bench typically require hundreds of episodes and minutes to hours of execution, stressing long-horizon planning, long-context management, and iterative debugging rather than one-shot problem solving. We evaluate 15 frontier models and find that agents consume on average 9.9M tokens per task, with roughly 231 episodes and 85.3 minutes of execution time per run, making Long-Horizon-Terminal-Bench more demanding than prior terminal-based benchmarks. Even the strongest tested model achieves 15.2% pass@1 at a partial-reward threshold of 0.95 and 10.9% at a perfect-reward threshold of 1.0, while the mean pass rate across models is 4.3% and 1.7% under the two thresholds, respectively. These results reveal headroom for improvement. We further analyze failure modes and error patterns, and release Long-Horizon-Terminal-Bench to support future progress on long-horizon terminal agents.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
Imagine asking a robot to finish a big computer project that takes many steps—like fixing a broken software tool, reproducing a science experiment, or playing through many levels of a game—using only a text window where it can type commands. This paper introduces a new test, called Long-Horizon-Terminal-Bench (LHTB), that checks how well AI “agents” can handle those long, realistic projects, not just short and simple ones. It also grades them more like a teacher with a checklist—giving partial credit for progress along the way—instead of only marking “pass” or “fail” at the end.
What questions did the researchers ask?
The paper focuses on a few simple questions:
- Can today’s AI agents make steady progress on long, multi-step computer tasks that take tens of minutes to hours?
- If we grade progress step by step (partial credit) instead of all-or-nothing, do we get a clearer picture of what the agents can and can’t do?
- Where do these agents usually go wrong: do they run out of time, stop too early, or get stuck in certain patterns?
How did they build the test and run the study?
Here’s the setup, explained in everyday terms:
- 46 realistic, long tasks across 9 areas: Things like reproducing results from a research paper, fixing software pipelines, analyzing images or videos, playing interactive games, and doing scientific computing. These tasks are designed to take many steps—think “marathon,” not “sprint.”
- Terminal-only work: The agent uses a “terminal,” which is a simple text box where you type commands to control a computer. No fancy buttons—just typing, running programs, editing files, and checking outputs.
- Subtasks with partial credit (dense rewards): Each big task is broken into meaningful “subtasks” (like checkpoints on a long hike). A built-in “grader” looks at the final computer state and gives points for each checkpoint completed. That way, the agent gets credit for partial progress, not just a final yes/no.
- Containers for fairness: Every task runs inside a “container” (think of it like a sealed, identical computer in a box) so each agent faces the same environment.
- Many steps and time: Tasks usually take hundreds of command steps (“episodes”) and can run for 30 minutes to hours.
- Models tested: The team tried 15 top AI models using the same agent “harness” (the wrapper that lets the model plan, act, and read results). They tracked how long tasks took, how many steps the agents tried, and how much progress they made.
Key terms in simple language:
- Terminal: A text-only control panel for a computer.
- Long-horizon: A challenge that needs many steps and sustained planning.
- Dense rewards: Frequent, detailed scoring that gives partial credit for progress.
- Subtasks: Mini-goals that add up to the final goal.
- Episodes: Iterations or turns where the agent decides what to do next.
What did they find?
Big picture: These long projects are hard for current AI agents.
- Much longer and tougher than past tests: On average, each run took about 231 steps and around 85 minutes—far more than earlier benchmarks that often wrap up in 20–30 minutes.
- Low pass rates even for the best: Even the strongest model they tested fully solved only about 15% of tasks at a generous “almost perfect” score threshold and about 11% at a “perfect” threshold. Across all models, the average pass rate was only about 4% (almost perfect) and 2% (perfect).
- Partial-credit grading matters a lot: Many runs made real progress without finishing. With simple pass/fail grading, those would all look like identical failures. Dense (step-by-step) grading showed which agents got “close,” which improved rankings and revealed useful differences.
- Common ways agents fail:
- Timeouts dominate: About 79% of failures happened because the agent was still working when the 90-minute limit ended—suggesting the main problem is finishing long projects on time, not just making single mistakes.
- Premature stopping: Some agents quit early, thinking they were done when they weren’t. This points to weak self-checking—a lack of “Are we truly finished?” judgment.
- Near-misses: There were lots of cases where agents got close (high partial scores) but failed the last few checks.
Why that’s important: These patterns show that long-term planning, memory, and self-verification (double-checking before stopping) are major weaknesses for today’s AI agents.
Why does this matter?
Real-world work—like maintaining software, reproducing experiments, or auditing data—often takes many steps and careful checking. This benchmark:
- Pushes AI toward real-life, long, multi-step projects rather than short demos.
- Gives better feedback: Partial-credit scoring shows where an agent is strong (e.g., early steps) and where it struggles (e.g., finishing touches).
- Highlights what to improve next: Agents need better long-term planning, better tracking of what’s done vs. what’s left, and better “stop when truly finished” judgment.
- Provides a shared testbed: Because LHTB is public, researchers can compare ideas fairly and measure real progress over time.
In short, this paper shows that while AI agents can handle short tasks well, they still have a long way to go on marathon-style projects. LHTB gives a tougher, fairer way to measure and improve them.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, concrete list of what remains missing, uncertain, or unexplored in the paper, phrased to guide future research.
- Subtask/reward design validity and sensitivity: No ablation on how different subtask decompositions, weightings, or aggregation functions affect rankings and behavior; no sensitivity analysis for the chosen 0.95 threshold versus alternatives.
- Grader robustness and security: The threat model for grader integrity is unspecified (e.g., can agents modify files, environment variables, or the grader to “game” partial credit?); no hardening measures or audits are reported.
- Reproducibility with hidden/dynamic verifiers: Hidden stress cases are randomized, but seeds, run-to-run variance, and reproducibility procedures are not reported; no repeated trials or confidence intervals are provided.
- Harness dependence and generality: Results are reported with essentially a single agent harness (Terminus-2; Codex for one model), with no ablations across prompting, memory, verification policies, or planner variants to separate model capability from harness policy.
- Budget scaling characteristics: All evaluations use a fixed 90-minute cap; there is no study of performance as a function of time/step/token budgets, nor of reward accumulation curves to reveal where progress stalls.
- Statistical rigor and variability: Pass@1 is reported without pass@k, multiple seeds, or confidence intervals; no significance testing or bootstrapped uncertainty on mean rewards or pass rates is included.
- Human baseline and task calibration: Task difficulty is tuned using a single model (DeepSeek V4 Pro) and lacks human expert baselines for time-to-completion or success rates; no calibration against human effort or proficiency is provided.
- Category taxonomy inconsistency: The paper alternately states “nine categories” and “21 high-level categories,” creating ambiguity about task taxonomy and comparability across domains.
- Representativeness and coverage: While diverse, tasks are constrained to terminal-only workflows inside containers; real-world long-horizon work often involves web APIs, GUI tools, and multi-application orchestration that are not represented.
- Hardware and compute standardization: Tasks may involve heavy computation (e.g., ML pipelines), but hardware specs, container resource limits, and their impact on runtime comparability are not documented.
- Token/cost normalization across models: Token accounting and pricing differ by provider; there is no normalization for tokenization schemes, caching policies, or pricing tiers, potentially skewing cost comparisons.
- Model configuration transparency: Sampling parameters (temperature, top‑p, seed), tool/plugin availability, context window usage, and retry policies are not standardized or fully reported, limiting fairness and reproducibility.
- Episode definition and comparability: “Episodes” are reported as a key metric, but the definition (e.g., command, loop, sub-goal) is not operationalized; comparability across task types remains unclear.
- Reward shaping and Goodhart risks: Dense partial credit may encourage optimizing for subtasks rather than end-to-end completion; no checks for reward hacking, perverse incentives, or misalignment between partial reward and true success.
- Multiple-solution validity: Deterministic graders may implicitly prefer a reference-style solution; it’s unclear how alternative correct approaches are recognized and scored across domains.
- Public vs hidden check weighting: The paper asserts lower weight for public checks but provides no quantitative breakdown; there is no analysis of how visible checks influence agent strategy or overfitting risks.
- Progress signal timing: Grading is done at rollout end; the benefits and risks of exposing subtask rewards online (for improved planning/verification) are not explored.
- Failure-mode localization: While timeouts and early exits are categorized, there is no fine-grained mapping from reward drops to specific workflow phases (e.g., environment setup vs. algorithmic repair vs. final verification).
- Early-exit/verification interventions: The paper diagnoses “false finishes” but does not evaluate interventions (e.g., explicit self-checklists, external verifiers, or mandatory end-game audits) or quantify their effects.
- Pass@k and best-of-n: Only pass@1 is reported; the effect of multiple attempts per task (common in practice) on cost–performance trade-offs is not characterized.
- Task stochasticity and fairness: Dynamic stress inputs may yield varying difficulty across runs; per-task variance and fairness checks are absent.
- Contamination and prior exposure: No contamination audit is presented to assess whether tasks, codebases, or solutions were present in model pretraining corpora.
- Language scope: Tasks appear to be English-only; generalization to other languages and locale-specific tooling is not addressed.
- Safety and ethical considerations: Some tasks (e.g., PoC exploit crafting) raise safety questions; sandboxing, red-teaming of tasks, and misuse mitigations are not discussed.
- Scaling the benchmark: At 46 tasks, statistical power for per-category comparisons is limited; the roadmap for expansion, versioning, and backward-compatible leaderboards is not specified.
- Cross-domain generalization: There is no analysis of how performance transfers across categories or which capabilities (planning, memory, debugging) limit generalization.
- Context-length effects: Tasks stress long-context usage, but the impact of different context windows, summarization strategies, and memory mechanisms is not controlled or measured.
- Open-world dependencies: Tasks intentionally avoid internet access; the impact of real external dependencies (APIs, credentials, rate limits) on long-horizon performance remains unexplored.
- Data and grader release details: With hidden verifiers, it’s unclear what artifacts are released, how to reproduce exact evaluations, and how to ensure community comparability without exposing solutions.
- Per-category diagnostics: Aside from high-level distributions, there is no detailed per-domain breakdown of difficulties, common error modes, or targeted benchmarks to isolate specific competencies.
Practical Applications
Immediate Applications
The following applications can be deployed today by leveraging LHTB’s containerized tasks, deterministic subtask graders, and cost/reward analytics.
- Bold pre-deployment evaluation for terminal agents in CI/CD (Software, DevOps, MLOps)
- Use LHTB tasks as a gating suite for agent rollouts that touch production repos, build systems, or data pipelines.
- Workflow: run
Harbor+Terminus-2in nightly CI; require minimum mean reward and [email protected] for promotion; block on regressions in long-horizon behaviors (timeouts, early exits). - Tools/products: internal “Agent QA Pipeline,” “Long-Horizon Regression Suite.”
- Assumptions/dependencies: Dockerized environments; compute budget (~85 min/task); access to target model APIs; LHTB tasks mapped to company-specific workflows.
- Model/vendor selection using the Pareto cost–reward frontier (Enterprise IT, Finance/Operations)
- Compare candidate models on [email protected] vs. per-task cost to choose cost-effective agents for automation.
- Workflow: reproduce Figure-like cost–reward plots on internal LHTB subset; set budget-aware thresholds (e.g., max $/pass at R≥0.95).
- Tools/products: “Model Sourcing Dashboard,” cost-aware agent router.
- Assumptions/dependencies: stable pricing, reproducible runs with token accounting; task representativeness for your use cases.
- Human-in-the-loop progress dashboards from dense rewards (Software, Data teams)
- Turn subtask reward into a live “progress meter” to support triage and escalation before timeout.
- Workflow: stream intermediate verifier checks; alert on “false finish” risk (high R but failing hidden checks); enable manual handoff to finish last mile.
- Tools/products: “Agent Progress Console,” “False-Finish Detector.”
- Assumptions/dependencies: exposing partial-grade signals safely; UI integration; ops policies for takeover/assist.
- Training data for process reward models and verifiers (AI/ML R&D)
- Repurpose deterministic subtask scores as supervised labels for PRMs, termination policies, and self-verification modules.
- Workflow: log trajectories + subtask outcomes; fine-tune PRMs to predict progress; teach agents when to continue vs stop.
- Tools/products: “VerifierKit” for exporting ground-truth subtask labels; offline RL/DPO pipelines.
- Assumptions/dependencies: licensing for training on benchmark traces; prevention of grader overfitting; compute for fine-tuning.
- Research reproducibility auditing (Academia, Publishing)
- Use experiment-reproduction tasks to validate paper claims and award replicability badges.
- Workflow: journals/labs run LHTB tasks tied to published artifacts; accept thresholds on mean reward and final checks.
- Tools/products: “Replicability-as-a-Service,” journal submission hooks.
- Assumptions/dependencies: author-supplied Docker images; domain-appropriate hidden stress tests; reproducible compute.
- Security and reliability hardening via long-horizon red teaming (Cybersecurity, Platform Trust)
- Exercise agents on tasks like
poc-exploit-craft, reverse engineering, and dataset tamper detection to discover failure modes (timeouts, premature stop). - Workflow: continuous stress tests; track false-finish rates; add mitigations (guardrails, verification rituals).
- Tools/products: “Agent Red-Team Suite,” risk scoring by horizon length.
- Assumptions/dependencies: safe sandboxes; responsible disclosure; updated stress inputs to avoid overfitting.
- Exercise agents on tasks like
- Pipeline resilience testing for data- and science-heavy orgs (MLOps, Scientific Computing, Climate/Geo)
- Validate agent performance on ML training orchestration, NetCDF processing, multimodal auditing, or SLAM pipeline repair.
- Workflow: simulate break-fix scenarios; require partial-credit progress minimums before granting broader system access.
- Tools/products: “Autonomous Pipeline Doctor,” pre-canned LHTB taskpacks per domain.
- Assumptions/dependencies: domain assets and simulators available; hidden evaluators capture true robustness.
- Curriculum and skills assessment for systems courses (Education)
- Adopt LHTB tasks as labs that grade partial progress for students or internal engineer upskilling.
- Workflow: instructors use deterministic graders; students see dense feedback instead of all-or-nothing marks.
- Tools/products: “Long-Horizon Autograder,” curated teaching taskpacks.
- Assumptions/dependencies: campus compute; simplified variants for course time constraints.
- Procurement/RFP benchmarking and compliance (Policy, Enterprise Governance)
- Require vendors to report [email protected] and mean reward on a public or org-specific LHTB slice before deployment.
- Workflow: standardized evaluation protocol; thresholds tied to risk tier (e.g., higher for safety-critical automations).
- Tools/products: “Capability & Horizon Certificate,” third-party audit service built on LHTB.
- Assumptions/dependencies: agreement on benchmark scope; periodic updates to prevent gaming.
- Power-user automation with verifiable partial progress (Daily life, Power users)
- Terminal assistants expose granular “how far did we get?” status, enabling users to resume work efficiently.
- Workflow: show subtask checklist; propose next best step after timeout; auto-generate issue summaries.
- Tools/products: “Agent To-Do from Partial Grade,” resumable terminal sessions.
- Assumptions/dependencies: local container support; privacy-safe logging; clear UX for long runs.
Long-Term Applications
These opportunities require further research, scaling, or ecosystem development to be practical.
- Architectures optimized for long-horizon completion (AI/ML R&D, Software)
- Design agents with explicit budgeted planning, durable memory, and calibrated stopping policies trained on dense reward signals.
- Products/workflows: “Budget-Aware Planner,” “Reflect–Verify–Act” loops, context compaction tied to subtask structure.
- Assumptions/dependencies: large-scale training on trajectory data; generalization across tasks without overfitting graders.
- Standardized capability ratings by time horizon (Policy, Risk, Insurance)
- Establish sector-wide “time-to-complete” ratings (e.g., 60–90 minute reliability tiers) using LHTB-like suites for procurement and safety cases.
- Products/workflows: certification regimes; insurance underwriting for automated ops based on horizon capability.
- Assumptions/dependencies: consensus on thresholds; accredited evaluators; periodic recalibration.
- Automated reproducibility at scale (Academia, Publishing, Pharma)
- End-to-end agents replicate papers, pipelines, and figures under verifiable graders; publishers integrate as submission gate.
- Products/workflows: “AutoReplicate” platforms, reproducibility badges enforced by hidden stress checks.
- Assumptions/dependencies: broader availability of containerized artifacts; robust, domain-specific verifiers (e.g., tolerance-aware metrics).
- Cross-domain “Verifier SDK” ecosystems (Software, Data Governance, Robotics)
- A common SDK to write deterministic, environment-grounded graders for any long workflow (terminal, cloud, or hybrid).
- Products/workflows: marketplaces of taskpacks and verifiers; org-specific grading libraries for compliance.
- Assumptions/dependencies: secure sandboxing; standardized artifact schemas; community curation to mitigate leakage.
- Agent orchestration and scheduling based on progress signals (Enterprise IT, Cloud)
- Multi-agent controllers allocate budgets, switch models, or request human help conditioned on subtask progress velocity.
- Products/workflows: “Agent Scheduler,” auto-escalation policies that minimize $/effective-progress.
- Assumptions/dependencies: reliable real-time grading; interoperable agent harnesses; cost-aware policies.
- Safety certification against false finishes and overconfidence (Healthcare, Finance, Critical Infrastructure)
- Require demonstrably low false-finish rates and robust self-verification before agents act on high-stakes systems.
- Products/workflows: calibrated termination models; mandatory cross-check rituals before exiting.
- Assumptions/dependencies: domain-specific hidden checks; incident reporting loops; risk-appropriate thresholds.
- Enterprise SLAs that measure progress, not just outcomes (Operations, BPO)
- Contractual “progress-based SLAs” where vendors are paid per validated subtask completion, discouraging premature exits.
- Products/workflows: metering and billing from partial reward; dispute resolution tied to deterministic graders.
- Assumptions/dependencies: legal frameworks for partial-credit billing; auditable grading logs.
- Benchmark-guided training loops (AI Labs)
- Closed-loop training where agents practice on evolving LHTB variants; PRMs and policies are iteratively improved using subtask feedback.
- Products/workflows: self-play for terminal tasks; curriculum learning from easy-to-hard subtasks.
- Assumptions/dependencies: scalable compute; methods to prevent overfitting to public checks; guarded hidden suites.
- Bridging to cyber-physical and robotics pipelines (Robotics, Manufacturing)
- Extend verifier-driven, long-horizon evaluation from terminal simulations to robot or lab automation workflows.
- Products/workflows: simulators with deterministic task graders; safe-to-fail sandboxes for hardware-in-the-loop.
- Assumptions/dependencies: reliable sim-to-real transfer; safety interlocks; multimodal artifact verification.
- Energy- and carbon-aware agent scheduling (Sustainability, Cloud FinOps)
- Combine cost–reward and energy telemetry to minimize emissions per unit of validated progress on long runs.
- Products/workflows: “Green Agent Orchestrator,” runtime policies that curb redundant exploration detected by progress stalls.
- Assumptions/dependencies: access to energy metering; accurate stall/loop detection from reward traces.
Notes on feasibility and dependencies across applications
- Containerization and sandboxing are foundational: Docker images, reproducible
solve.sh, and reliable simulators/verifiers are prerequisites. - Hidden stress tests must reflect real variability; otherwise, agents may overfit public checks.
- Compute/time budgets are nontrivial: average ~231 episodes, ~85 minutes, and millions of tokens per task; caching and batch scheduling reduce costs.
- Access to frontier models and stable pricing affects cost–reward trade-offs; local or fine-tuned models may change the Pareto frontier.
- Governance and safety uses need agreed-upon thresholds and third-party auditors to prevent gaming and ensure comparability.
Glossary
- agent harness: A software layer that orchestrates how an AI agent interacts with an environment (e.g., tools, sessions, stopping rules). "the Terminus-2 agent harness"
- campaign-style tasks: Long-running, multi-episode tasks (such as games or repeated audits) evaluated over many trials. "Campaignâstyle tasks (e.g., games or repeated audits) aggregate across episodes."
- containerized terminal environment: An isolated, reproducible command-line workspace packaged in a container to run tasks end-to-end. "a containerized terminal environment"
- dense reward: An evaluation signal that provides frequent, informative feedback for partial progress instead of only final success/failure. "dense intermediate rewards"
- deterministic grader: A fixed, non-stochastic evaluator that checks state and outputs to score progress consistently. "a deterministic grader that runs inside the container at the end of a rollout."
- Docker image: A packaged filesystem and configuration that defines the software environment for a task. "The Docker image contains all relevant assets, code, data, tools, and helper scripts"
- early exit: An agent-initiated termination of a run before time or resource limits are reached, often prematurely. "early exits (the agent terminates on its own with no harness error)"
- episode-aggregating subtasks: Subtasks that compute performance across multiple runs or levels rather than a single attempt. "Episodeâaggregating subtasks."
- false finish: A premature stop where the agent believes it has completed the task despite failing hidden checks. "We define a false finish as an early exit at relatively high reward"
- gold solution: The official, verified implementation that achieves perfect score under the hidden evaluator. "The official gold solution is required to achieve a verifier score of $1.0$"
- Harbor framework: A system for evaluating and optimizing agents within containerized environments. "the Harbor framework"
- hidden verifier: An unseen evaluation program or suite of checks used to prevent overfitting to public tests. "and a hidden verifier."
- long-context: The extended state or history that an agent must remember and update over many steps. "manage evolving long-context state"
- long-horizon: Tasks that require many steps, sustained planning, and extended execution time to complete. "long-horizon terminal tasks"
- NetCDF: A scientific file format used for array-oriented data, common in climate and geoscience workflows. "climate NetCDF extreme-event detection"
- normalized reward: A score scaled to a fixed range (often [0,1]) to compare progress across tasks or subtasks. "mean normalized reward across all tasks"
- oracle implementation: A trusted reference or ground-truth program used to grade or simulate correct behavior. "an oracle implementation or simulator used for grading"
- Pareto frontier: The set of models that are not outperformed simultaneously in both cost and reward; a trade-off curve. "the Pareto cost--reward frontier"
- partial credit: Awarding points for incomplete but meaningful progress toward the final objective. "dense intermediate rewards and partial credit"
- pass@1: The probability of solving a task in a single attempt, a standard metric in code/agent benchmarks. "achieves pass@1 at a partial-reward threshold of 0.95"
- prompt-cache: A provider-side mechanism that can reduce costs by caching repeated prompt segments. "prompt-cache discounts are not guaranteed across providers."
- reference solution: A correct implementation or script that demonstrates the intended completion path for a task. "with a reference solution or simulation engine"
- reward threshold: A cutoff value on the normalized score used to count a task as successfully solved. "a partial-reward threshold of 0.95"
- self-verification: An agent’s ability to check its own outputs and determine whether goals have actually been met. "weak self-verification."
- simulation engine: A programmatic environment that emulates task dynamics to evaluate agent actions. "reference solution or simulation engine"
- SLAM: Simultaneous Localization and Mapping, a robotics technique for building a map while tracking position. "robotics SLAM pipeline"
- stress cases: Hard or adversarial test inputs designed to probe robustness and prevent overfitting to public checks. "hidden stress cases that dynamically generate harder inputs"
- subtask-based grading: Evaluating tasks via a set of intermediate, semantically meaningful checks that each contribute to the final score. "Subtask-based grading"
- Terminal-Bench formulation: A benchmark setup where tasks are solved entirely from a command-line interface within containers. "follows the Terminal-Bench formulation"
- timeout: Automatic termination of a run when the allotted time budget is exhausted. "90-minute timeout"
- wall-clock time: The real elapsed time taken by an end-to-end run, as opposed to CPU or simulated time. "85.3 minutes of wall-clock time"
Collections
Sign up for free to add this paper to one or more collections.