On May 8, METR added Claude Mythos Preview to its time-horizon chart and wrote two numbers next to it. The model finishes tasks that take a skilled human at least 16 hours about half the time. It finishes tasks that take a human 3 hours and 6 minutes about four times in five. METR also added a warning: measurements above 16 hours are unreliable with its current task suite (METR, May 8, 2026).
Most coverage quoted the first number. I keep looking at the second, and at the distance between the two. At 50%, a sixteen-hour run is a coin flip, and you cannot tell which side it landed on without checking the work. The stretch from the 80% horizon to the 50% horizon is where agent infrastructure earns its keep: checks that tell a good run from a bad one, retries that cost a piece instead of the whole job, checkpoints that keep finished work, and proof that a person can read.
What the two numbers measure
METR gives an agent a suite of software, machine-learning and security tasks, each timed against skilled professionals who did it by hand. It then fits a logistic curve of the agent's success against the human completion time. The 50% horizon is the task length where the curve crosses one half; the 80% horizon is where it crosses four in five.
For Mythos Preview, METR's raw results, as published May 8, 2026, put the 50% point estimate at 17 hours 25 minutes, with a confidence interval from 8 hours 29 minutes to 55 hours. METR reports it as "at least 16 hours" because the suite runs out of long tasks. The 80% horizon is 3 hours 6 minutes, with an interval from 1 hour 37 minutes to 6 hours 39 minutes (METR, May 8, 2026). METR's Frontier Risk Report of May 19, 2026 puts the 80% horizon of the most capable model it was shown between 3 and 4 hours.
The trend line is steep. In Time Horizon 1.1, published January 29, 2026, METR estimated that the 50% horizon has doubled about every 131 days since 2023. A number that doubles four times in eighteen months deserves attention, and so does the reliability that comes with it.
The gap holds across models
Mythos is the extreme case. The same ratio shows up across every recent frontier model METR has measured.
For each of these models, the task an agent finishes half the time is four to ten times longer than the task it finishes reliably. Claude Opus 4.6 sits at 11 hours 59 minutes against 1 hour 10 minutes, a factor of ten. GPT-5.4 sits at 5 hours 42 minutes against 54 minutes (METR results, April and February 2026). Capability and dependability grow together, and dependability stays roughly two to three and a half doublings behind.
A coin flip you cannot read
METR publishes two points on one curve, so the rest of the curve follows from them. Here is the success rate implied for Mythos across task lengths, using METR's own logistic shape and its two published horizons.
The curve falls slowly. At one hour the implied success rate is about 91%. At eight hours, about 65%. At sixteen hours it is close to a coin flip, and the shaded region past that is where METR says its measurements become unreliable.
The benchmark hides one advantage that real work lacks. Every METR task ships with a scorer, so METR knows which half of the runs failed. Your sixteen-hour job has no scorer unless you build one. The agent will finish either way, write a confident summary either way, and open a pull request either way. Without a check, the failed half and the successful half look the same at the moment you read them. I wrote about the cost of that in Every Agent Demo Hides the Same Number: a demo sets the cost of failure to zero, and production charges it in full.
What fills the gap
Here is the arithmetic that convinced me the gap is an infrastructure problem as much as a model problem. Take a sixteen-hour job and three ways to run it.
Run it whole and you get METR's coin flip. Cut it into five pieces of about three hours and run them back to back with no checks, and it gets worse: 0.8 multiplied by itself five times is 33%. Smaller pieces only help when something between them tells you a piece failed. Add a check after each piece, retry a failed piece once from where the last good piece left off, and the same model, at the same per-piece rate, finishes the whole job about 82% of the time.
Four things do that work, and none of them is the model:
Checks. Tests, a build, a linter, a second agent reading the diff, a human reading the result. Anything that returns pass or fail on a piece of work without trusting the author's own account of it.
Retries. A failed piece runs again, bounded, so a bad hour costs an hour. Retries only pay when a check can tell you which piece to retry.
Checkpoints. The work from the first four good pieces survives the fifth one failing. Files, commits and the agent's own trajectory need to be saved as the run goes, so a retry can start from the last good state instead of from the request.
Proof. The result arrives with the evidence a person needs to accept it quickly: the checks that ran, what they returned, and what the agent did along the way. The org-chart post argued that review rate caps what agents produce; proof is how review gets faster.
Honest limits
The arithmetic is generous. Failures are rarely independent: a piece that failed because the task is hard tends to fail again on retry. Checks are never perfect; a test suite that misses a bug passes a bad piece. Real jobs rarely split into five equal, separable pieces, and METR's tasks are a specific mix of software, research and security work with human timings behind them. The 82% figure is an upper bound under clean assumptions, and I would expect real numbers below it.
The direction holds anyway. A model whose 80% horizon is three hours can do sixteen hours of work you can depend on only if the work is cut where it can be checked, saved where it can be resumed, and handed back with evidence. Each of those is a property of the system around the model.
What we build for it
This is the reason a Rush run ends the way it does. A request starts an agent in a cloud sandbox with a git worktree of its own, and its output streams back live while it works. A code run counts as complete only when it hands back a pull request, and review happens there, on GitHub, where the repository's checks run. A run that finishes without a pull request is marked needs_review and waits for a person to follow up. You can send a run a follow-up message, or cancel it, while it works. That puts part of the coin flip in the open: a run that produced no pull request says so, and a person spends review time on the runs that need it.
The 50% horizon will keep doubling. If both horizons keep METR's pace of about 131 days per doubling, the 80% horizon reaches today's sixteen hours roughly two and a half doublings from now. Until then, every hour between the two numbers belongs to whoever checks the work.
