Long-horizon tasks

What are long-horizon tasks?

A long-horizon task is a job that takes a person hours or days and only works if a long chain of dependent steps all go right. Migrating a customer file from one CRM to another, rebuilding a set of reports after an ERP change, or tracing why last month's margin figure is wrong: none of those is one action. Each is fifty or five hundred actions, and step forty depends on step twelve having been done properly.

The "horizon" in the name is a time horizon: how far ahead an AI agent can work on its own before the odds of a clean result drop below what you would accept. A model that answers a single question well can still lose the thread halfway through a three-hour job. The length of job it can carry to the end is a separate capability from how smart it looks in a chat window.

The research group METR turned that idea into a number in 2025. Their time horizon metric is the length of a task, measured in the time a skilled person needs for it, that a model completes at a given success rate. The headline version uses 50 percent. If a model's 50 percent time horizon is two hours, it finishes about half of the tasks that would take an expert two hours, and far more of the tasks that take ten minutes.

METR describes what the metric captures in one line: the amount of serial human labour a model can replace at a 50 percent success rate. Serial is the important word. It is about how many dependent steps a model can string together, not about how much it knows.

How the time horizon is measured

The method matters because you will see the number quoted in vendor material, and a number you cannot interpret is a number you cannot argue with.

Humans go first. METR pays skilled professionals in software engineering, machine learning and security, with about five years of relevant experience on average, to complete each task under the same instructions and with the same tools the agents get. The task's length is the geometric mean of the successful human times. Failed human attempts are left out, which METR itself flags as a possible source of underestimation.

Then the agent runs each task several times. On a suite of a couple of hundred software and research tasks, from a few seconds to over eight hours of human time, each agent gets multiple independent attempts per task. That gives a success rate per task.

Then a curve is fitted. METR plots success rate against the logarithm of human task length and fits a curve through it. The point where the curve crosses 50 percent is the 50 percent time horizon. Where it crosses 80 percent is the 80 percent time horizon.

One thing follows for anyone reading the numbers: the horizon is a statistical fit across many tasks, so the error bars are wide. METR puts them at roughly a factor of two in each direction for recent models. A model quoted at eight hours may sit anywhere between four and sixteen on the same data.

How fast the horizon is growing

Rounded, the numbers METR has published look like this.

• In March 2025 the best model, Claude 3.7 Sonnet, had a 50 percent horizon of roughly 50 minutes to an hour.

• In August 2025 METR measured GPT-5 at a 50 percent horizon of about two and a quarter hours.

• In January 2026, on an expanded task set, Claude Opus 4.5 came out at roughly five hours.

• In May 2026 METR reported at least 16 hours for an early version of Claude Mythos Preview, with a confidence interval running from about 8 to 55 hours, and added a warning that anything above 16 hours is unreliable with the current task suite because there are too few tasks that long.

Across 2019 to 2025 that horizon doubled about every seven months. Since 2024 the pace has been faster: METR's January 2026 update puts the doubling time since 2024 at roughly three months, and around four if you start counting from 2023. Extrapolating from that gets you month-long tasks within a couple of years. METR itself calls that kind of extrapolation fraught, because nobody has a good definition of which kinds of tasks the suite stands for.

For a business the direction is more useful than the exact curve. Whatever an agent could not finish last year, it may well finish next year, so keep a short list of jobs you tried and shelved, and retest them every few months.

50 percent horizon versus 80 percent horizon

The 50 percent horizon is the number that gets quoted. The 80 percent horizon is the one a business should look at, and it is a lot shorter.

In METR's data a model's 80 percent horizon is typically four to eight times shorter than its 50 percent horizon. GPT-5 is a clean example from METR's own report: about two and a quarter hours at 50 percent, about 25 minutes at 80 percent. The early Mythos Preview measurement has the same shape: at least 16 hours at 50 percent, a little over three hours at 80 percent.

Put the two side by side on the dimension that matters to you, which is how reliable a result has to be before you stop checking it.

The 50 percent horizon tells you what a model can sometimes pull off. That is a good number for deciding what to experiment with. It is a coin flip on whether any given run succeeds, so you cannot plan a process around it.

The 80 percent horizon tells you the length of job a model gets right four times out of five. For work where a person reviews the result anyway, that is workable: a one-in-five miss is a review cost, not a disaster.

Neither number is 99 percent, and METR is explicit that it cannot measure a 99 percent horizon: doing so would need around 300 varied tasks in every length bucket. If a process cannot tolerate one failure in five, the horizon metric does not tell you an agent can run it. It tells you how long a piece of that process an agent can take on before your check.

Why long tasks fail

METR's finding that explains most of it: agents seem to struggle more with stringing together longer sequences of actions than with the individual steps. The single step is usually within reach. The chain is what breaks.

Mistakes compound. A model that makes a small error early, a wrong column mapping in a migration or a wrong assumption about a date format, then builds sixty more steps on top of it. Nothing later corrects it unless something checks it. METR notes that the gains in time horizon over the last two years have come largely from models getting better at adapting to their own mistakes instead of repeating them, which tells you how central this failure mode is.

Messy environments hurt more than long ones. Controlling for length, METR found that models do worse on tasks scored as messier: tasks without a clear feedback loop, or where the agent has to go and find out things it was not told. Most real business work is messy in exactly that sense. The instruction is "sort out the supplier master data", not "rename these 40 fields".

State gets lost. A long job produces a lot of intermediate results, and the agent has to carry them in its context. Earlier decisions blur, the model rereads and reinterprets its own notes, and by hour three it no longer holds the picture it had at minute ten. Context rot and the limits of the context window are the mechanics behind this.

None of these is fixed by a smarter model alone. They are contained by how you cut the work.

What this means for what you hand to an agent

The metric gives you a practical rule: hand an agent pieces of work that are shorter than its 80 percent horizon, and put a check between the pieces.

Take a month-end reconciliation that costs a bookkeeper three hours. Given to an agent in one go, that sits around the edge of the 80 percent horizon of today's best models, and you only find out at the end whether it worked. Cut it instead into four pieces of about 45 minutes, bank matching, open invoices, intercompany, review notes, with a check after each: totals match, row counts match, the exceptions list exists and is explained.

The arithmetic is against you without those checks. If each piece succeeds nine times out of ten, the chance that all four go right unchecked is 0.9 to the power four, roughly two in three. With a check after each piece, a failure costs you one 45-minute rerun instead of a three-hour job redone from the start.

The pattern that falls out of this:

1. Start with tasks under an hour of human time. That is the range where current models are reliable enough that a review step is a formality rather than a rescue.

2. Give every piece a check the agent can run itself. A row count, a total that must match the source, a test that must pass. Without one, "looks done" is the only signal the agent has, and you become the check.

3. Save state at each checkpoint. Write the intermediate result to a file or a table so the next piece starts from a known artefact rather than from the agent's memory of what it did.

4. Put a human review at milestones, not at every step. Review the field mapping before the migration runs, review the exceptions list before anything is posted. In between, let the checks do the work.

5. Keep the long version for later. When the same job has run cleanly in pieces for a few months, try merging two pieces. Your own logs are a better guide than any published curve.

What to watch out for with long-horizon claims

Ask which horizon. If a vendor says "handles day-long tasks", ask whether that is the 50 or the 80 percent figure, and on which tasks. A day at 50 percent is a few hours at 80 percent.

The metric is measured on software work. METR reports that horizons are similar for maths tasks but 40 to 100 times shorter for tasks that involve using a computer visually, such as clicking through screens. If your job runs through a web portal without an API, do not assume the headline number applies.

The tasks are clean. Every task in the suite is self-contained, has clear instructions and a clear finish, and needs no collaboration. A vendor quoting a 16-hour horizon for an agent that has to work through your inbox, your ERP and a phone call to a supplier is borrowing a number measured in a very different setting.