The Four-Minute Agent and the Four-Hour Task

The Four-Minute Agent and the Four-Hour Task is the observation this entire book is built on. The same system that is nearly flawless on short work becomes unreliable on long work, and the transition happens over a range you can measure. Capability scores hide it, because a score is an average over a task set somebody else chose.

Key takeaways

• The useful measurement is a horizon, not a score: the human-time length at which an agent's success rate crosses some threshold you are willing to live with.
• METR revised its time-horizon estimates in January 2026, reporting a post-2023 doubling time of 131 days against 165 days previously, on an expanded suite of 228 tasks.
• Read the intervals, not the point estimates. METR's 50% horizon for Claude Opus 4.5 is 320 minutes with a range from 170 to 729, which is a factor of four.
• A horizon is a property of a task distribution, not of a model. Reliability on software engineering tasks degrades far faster than on document processing in the same study.
• The published horizon is not yours. Chapter 11 builds the measurement for your own workload, and every architectural decision in between is priced against it.

Read this beside Chapter 2, which explains why the curve falls the way it does, and Chapter 11, which is where you build your own. The evaluation practice underneath both is in an evaluation harness that guides releases.

Give an agent a task that a competent engineer would finish in four minutes and it will almost always succeed. Rename a symbol across a repository. Fix an off-by-one. Summarise a document into a structured record.

Give the same agent a task that would take that engineer four hours and something different happens. It does not fail loudly at the halfway mark. It produces four hours of confident work with a wrong decision at minute forty.

The number people quote is a horizon, and it has moved

METR measures this directly, and their metric is the one to know. The 50% time horizon is the length of task, measured by how long human experts take, that a model completes successfully half the time. It converts a capability question into a duration, which is the unit an engineer planning work actually thinks in.

That metric was widely quoted from METR's March 2025 post, which reported a doubling roughly every seven months. Fetch that page today and it carries a banner saying its text and figures are out of date. The current statement is Time Horizon 1.1, published 29 January 2026, and the revision is not cosmetic. The task suite grew from 170 to 228 tasks, the number of tasks taking over eight hours more than doubled from 14 to 31, the evaluation infrastructure moved from Vivaria to Inspect, and 14 models were re-estimated. Under the new methodology, METR puts the post-2023 doubling time at 131 days rather than 165.

Two things follow, and the second matters more.

The trend is faster than the number most people are carrying. And the number most people are carrying is sixteen months old, from a page that now warns you about itself. In a field this fast, a citation without a date is not evidence.

Read the interval, not the point

The headline figures from Time Horizon 1.1 are worth stating precisely, because the precision is the lesson.

Claude Opus 4.5 has a 50% horizon of 320 minutes, with a confidence interval running from 170 to 729 minutes. GPT-5 is at 214 minutes, interval 117 to 480. The o3 model sits at 121 minutes, interval 74 to 201.

Look at the Opus interval. The upper bound is more than four times the lower. That is not a criticism of the measurement, which is careful, and METR says plainly that the intervals remain very wide and that the metric is sensitive to task composition. It is a statement about what the measurement can support. If your architecture assumes five hours of unattended work because the point estimate says 320 minutes, you have built on the middle of a range whose bottom is under three hours.

There is a further gap that no interval covers. Fifty per cent is a coin flip. A 50% horizon of five hours means half of five-hour tasks fail, which is nowhere near the reliability any production system needs, and the horizon at 80% success is much shorter than the horizon at 50%.

The horizon you can deploy against is much shorter than the published one

Fifty per cent is chosen for measurement reasons rather than operational ones. It sits where a fitted curve is steepest and best determined, which makes it a good statistic and a poor service level.

Translate it into your own terms before designing anything. If a task family fails half the time, every unattended run needs either a human reviewing the output or a verification step that catches the failure automatically, and both of those have a cost per run that has to be paid on the successes too. The economics of an agent are set by that cost, not by the model price.

Work backwards from the consequence instead. Ask what success rate makes the work worth automating given what a failure costs, then find the task length at which the system reaches that rate. For a task where a wrong result is caught immediately and cheaply, 50% may genuinely be fine, and a retry loop turns it into 75%. For a task that writes to a customer-facing system, the required rate is high enough that the usable horizon may be a small fraction of the published one.

Two consequences follow for the rest of this book. The first is that horizon extension is an architectural goal rather than a model-selection one: verification, checkpoints and compensation all move your usable horizon to the right without changing the model underneath. The second is that a retry is only worth anything if the failure is independent, and in a long task it usually is not, because the second attempt inherits the same wrong state that produced the first failure. That is the subject of the next chapter.

There is also a reporting discipline here. When someone in your organisation says an agent is 90% reliable, ask three questions: on what task length, at what success threshold, and measured over how many runs. Most claims of this kind dissolve under the first question, and the dissolution is useful rather than embarrassing.

Success rate is not the thing that breaks

The second reason a score misleads is that averages hide the shape of failure, and the shape is where the engineering lives.

Khanal, Tao and Zhou argued this in March 2026 in a framework they call reliability science, proposing four measures to replace single-attempt success: a reliability decay curve, a variance amplification factor, a graceful degradation score, and a meltdown onset point. Their finding across domains is the one to hold onto. Reliability does not decay uniformly. In their tests, software engineering tasks fell from 0.90 to 0.44 across the horizon while document processing stayed close to flat.

Two of their secondary results are more uncomfortable. Model rankings change on longer horizons, so the model that wins your short-task evaluation is not necessarily the model that survives your long ones. And frontier models showed higher failure rates in places, because they attempt multi-step strategies that shorter-sighted models never start.

Capability and reliability are different axes. A more capable model attempts more, which gives it more ways to be wrong at step thirty.

Where the failures actually occur

Knowing the curve falls is not the same as knowing where.

Wang and colleagues published a diagnostic framework in April 2026, working across four domains and more than 3,100 recorded trajectories, using a trajectory-grounded judge validated against human annotation at a kappa of 0.84. The value of that work for a practitioner is not its taxonomy. It is the demonstration that failures in long tasks are locatable: they happen at identifiable steps, for identifiable reasons, and the record of the run contains enough information to say which.

That is the premise of everything after this chapter. If failure were diffuse, the only remedy would be a better model. Because failure concentrates at particular steps, it can be engineered against, with verification at the step that fails, a checkpoint before it, and a compensation for the effect it causes.

Anthropic's engineering guidance from December 2024 makes the complementary point from the other end: start simple and add complexity only when needed, because agentic systems trade latency and cost for task performance. The reliability work in this book is that complexity. It is worth adding when your horizon requires it, and not before.

Why the four-minute case creates the four-hour problem

The excellence at short tasks is what makes the long-task failure expensive.

Short tasks succeed at a rate that trains everyone involved to stop checking. The demo works. The pilot works. The first fifty runs work, because they are short, and the team calibrates its trust on that sample. Then a long task arrives, the agent takes an incorrect action at minute forty, and no part of the surrounding system was built to notice, because nothing has needed noticing yet.

There is a second-order effect worth naming. Trust that is calibrated on short tasks gets spent on long ones, and it gets spent by people who are not watching. The operator who reviewed the first twenty outputs stops reviewing by the fiftieth. That is not negligence, it is exactly how humans respond to a reliable-seeming process, and any architecture that depends on sustained human vigilance has assumed something false about the humans.

So the design question is not how to make the agent better. It is what the system does when the agent is wrong at minute forty and nobody is looking.

What this book does about it

The rest of the book is one argument in eleven moves, and the order is deliberate.

Chapter 2 explains why errors compound rather than average out, which is the mathematical reason the curve falls. Chapters 3 to 6 build the recovery machinery: decomposition as an artifact the runtime can read, checkpoints that make a restart cheap, verification gates that catch a wrong commitment before it propagates, and compensating actions for effects that have already left your system. Chapter 7 puts that machinery on a durable execution foundation, because none of it survives the process dying otherwise. Chapter 8 covers the tools, which are the real interface, and chapter 9 the four budgets that bound the damage. Chapter 10 designs the handoff to a human. Chapter 11 measures your own horizon. Chapter 12 puts the whole thing on call.

None of it requires a better model, and all of it is cheaper than the incident it prevents.

Chapter summary

The gap between four-minute competence and four-hour unreliability is the subject of this book, and it is measurable rather than anecdotal. METR's 50% time horizon converts capability into duration, and its January 2026 revision moved the post-2023 doubling time to 131 days on an expanded suite of 228 tasks, with the March 2025 post that most people still quote now carrying an out-of-date banner. The point estimates matter less than the intervals: Claude Opus 4.5 at 320 minutes carries a range from 170 to 729, and fifty per cent success is a coin flip rather than a service level. Reliability decays by domain rather than uniformly, with software engineering falling from 0.90 to 0.44 in one 2026 framework while document processing held steady, and model rankings themselves change at longer horizons, so a short-task evaluation does not predict a long-task deployment. Failures are locatable rather than diffuse, which is what makes them an engineering problem instead of a model problem. And the excellence on short tasks is precisely what makes the long-task case dangerous, because it calibrates human trust on a sample that does not represent the work.

The next question is why the curve has that shape. Chapter 2 is Why Failures Compound: The No-Recovery Bottleneck, which shows that per-step accuracy multiplies rather than averages, that a retry cannot fix a wrong state it has already inherited, and that the bottleneck in long-horizon work is not perception or planning but the absence of any path back.