Correction, October 9, 2026: An earlier version treated task-completion time horizons as a measure of how long an AI can run reliably. They measure task difficulty using human completion time, not the agent's elapsed runtime. We have corrected that framing and removed unsupported time-based delegation bands. The original publication date is unchanged.
A two-hour AI time horizon does not mean an agent can work unsupervised for two hours. It means something narrower: on the evaluated task distribution, tasks taking a human expert about two hours sit near the system's estimated success threshold.
For a 50% time horizon, that threshold is success about half the time. The AI might spend much less than two hours attempting the task. The distinction matters when a benchmark number becomes a promise about what a system can safely own.
What the clock measures
METR's methodology starts with tasks, human completion-time estimates and observed AI successes and failures. A fitted curve relates success probability to human task duration. The point where that curve crosses 50% gives the 50% horizon; an 80% horizon uses a higher reliability threshold.
The unit is intuitive, but it is still a statistical estimate. It does not say every two-hour task has the same difficulty for AI, or that an individual task will succeed on half of all attempts. Aggregate capability and consistency on a particular case are different questions.
Nor does the curve diagnose why a run failed. A poor result alone cannot tell us whether the cause was memory loss, a bad plan, a tool problem or missing knowledge. Those explanations require evidence from the runs themselves.
A software task is not a working day
METR's published task suite primarily covers software engineering, machine learning and cybersecurity. The tasks are self-contained, relatively well specified and designed to have checkable success criteria. That makes comparisons possible, but it limits how directly the result transfers to an actual job.
The human comparison also needs context. METR describes its baselines as closer to work by a skilled newcomer or contractor with little prior project context than by an employee who already knows the code, people and history. An eight-hour benchmark task is not automatically equivalent to an experienced colleague's working day.
METR's March 2025 analysis reported rapidly increasing horizons in its historical data. That is evidence about performance on the measured tasks, not a guarantee that the same growth rate will continue. The original post now warns that some figures and claims are out of date, and its linked measurement page says it is no longer actively updated.
Use the metric to ask a better delegation question
Before handing over a workflow, ask whether its tasks resemble the evaluation, what success rate is acceptable and how failures will be detected. A 50% threshold can be useful for comparing research progress while being far below the reliability needed for an unattended consequential action.
Checkpoints, restricted permissions and recovery procedures can be sensible controls. Their design should follow the actual task and cost of failure, not universal one-hour or three-hour bands inferred from this benchmark.
For the separate question of repeated success on the same case, see our chart of simulated AI customer-service runs.
The useful claim is not that an agent has acquired a certain number of hours of endurance. It is that, under a stated evaluation and reliability threshold, it can solve a harder class of tasks. Turning that into dependable work still requires knowing which tasks, which failures and which safeguards matter.
