A fifty-percent task horizon is not a staffing plan
METR’s March 2025 task horizon compared capability through human task duration. Deployment still needs acceptable failure rates and a workable recovery process.
By 
Paul. AI and agentic engineering
A task horizon measured at fifty-percent success is a useful capability comparison and a poor basis for promising unattended delivery. The missing business variables are the acceptable failure rate, the cost of finding and repairing mistakes, and the kinds of tasks that actually arrive. METR's March 2025 work gave technical leaders a better language for discussing duration. It did not turn human task duration into a staffing ratio.
This November 2026 retrospective uses the original paper, version one, submitted on 18 March 2025, for the historical result. It defines the metric using the time humans typically need for tasks that models complete with fifty-percent success. The 19 March announcement now also displays a later, updated live chart. That chart is not a frozen record of what was known during the publication week.
Duration belongs to the human baseline
Human completion time makes an unfamiliar evaluation easier to interpret. A task associated with an hour of expert work sounds more concrete than an abstract score. But the axis describes a human baseline, not a guarantee that an agent can remain productive for an uninterrupted hour. It also does not specify how long the agent itself takes to finish.
Version one reported a roughly fifty-minute horizon for a then-frontier model and an approximately seven-month doubling trend since 2019. Those are attributed historical findings. Neither establishes the horizon of a November 2026 system, nor the performance of a particular assistant working inside a buyer's repository. Keeping that distinction explicit preserves the value of the original result without importing later capability claims.
There is another limit inside the threshold. Fifty-percent success describes a fitted relationship over an evaluation distribution. It does not mean every task at that human duration has the same probability of success. Two tasks can take a person equally long while presenting very different obstacles to an automated system. Duration compresses those differences into a useful comparison, but cannot remove them.
For an illustrative planning decision, consider assistance with routine report preparation. Some reports may have clear inputs and an easily checked total. Others may require resolving an ambiguous request with another department. Calling both “an hour's work” does not establish that the same autonomy policy should apply to both.
Failure creates work of its own
A failed attempt can be cheap when it produces nothing and the original task remains easy to restart. It can be expensive when it leaves plausible changes that a person must inspect before continuing. A deployment decision needs that distinction, because the recovery burden can determine whether assistance actually releases capacity.
Detection belongs in the same calculation. An obviously incomplete report and a convincing report with a wrong customer allocation are different operational outcomes. A success threshold alone does not tell a team which errors it will notice before the output reaches someone else. The acceptance process needs to match the consequence of the particular task.
A proposed evaluation should preserve unsuccessful and abandoned attempts alongside accepted results. Record who detects a problem, what can be restored and when a human takes over. This is a suggested measurement design, not an experiment carried out here. It avoids inventing a failure budget from the historical benchmark or assuming that retries always recover the task.
The business owner should set the acceptable outcome before selecting a model. Drafting an internal summary may tolerate a different review burden from changing a payment record. A single capability curve cannot choose that tolerance. It can help identify candidate work once the business has defined what an unacceptable failure would mean.
A trend supports scenarios with conditions
Extrapolating a measured trend can be useful. It encourages a team to examine what would change if longer tasks became tractable, rather than organizing permanently around today's limits. The original paper explicitly conditioned its forecast on generalization to real-world software tasks. That condition is part of the finding, not a footnote to discard when preparing a budget.
The strongest counterargument to caution is that waiting for certainty can leave an organization unprepared. That is reasonable. A scenario can justify documenting repetitive work, separating reversible actions from consequential writes, or preparing better acceptance criteria. These investments may remain useful even if the extrapolated capability arrives later than expected.
A service commitment is a different decision. It needs evidence for the selected system and task distribution, with enough operating provision for failure and recovery. A historical trend cannot supply a delivery date, an availability promise or the number of staff who can be removed. Those require evidence about the actual process being changed.
This distinction also separates the topic from SWE-Lancer's payout weights. A historical freelance price asks how to weight benchmark tasks economically. METR's duration metric asks how capability varies with human task length at a selected reliability threshold. Neither number, by itself, prices the complete delivery process a business must operate.
Start with one class of work
For a proposed rollout, choose a bounded task class with a clear acceptance decision. Describe the incoming work honestly, including awkward examples. Define what the system may change and where a person must intervene. Then compare the accepted output and recovery effort with the existing process, preserving the same acceptance standard.
For custom software development, this creates a concrete discussion about autonomy: which work can proceed, which failures are tolerable and who owns recovery. Use the March horizon as evidence that task duration matters. Use project evidence to decide what the business can rely on. A capability forecast becomes useful when its conditions survive contact with the operating plan.