METR Time Horizon 2.0—The benchmark you’ve been waiting for

A researcher applied METR's time-horizon methodology to Microsoft Excel and found it completes tasks requiring 6.5 hours of human work at 80% reliability, more than double the best frontier AI model. The finding raises concerns about unmonitored spreadsheet capabilities, with the researcher updating their probability of spreadsheet-induced catastrophe by 2035 from 0.1% to 5–10%.

TL;DR: I applied METR's time-horizon methodology to Microsoft Excel. On my 23-task suite, Excel completes tasks that take an unaided human 6.5 hours at 80% reliability — more than double Claude Mythos Preview, the best frontier model on the current METR plot ~3 hours at 80% . Excel's 50%-time horizon is 54 working weeks. I have updated my probability of spreadsheet-induced catastrophe by 2035 from 0.1% to 5–10%. Then I wrote down everything wrong with my methodology and noticed I had written a review of the METR plot. METR measures a model's “time horizon”: the task duration, measured by human completion time, at which an agent is predicted to succeed with a given reliability https://metr.org/time-horizons/ . You fit a logistic curve of success against log task length and read off where it crosses 50% or 80%. I did exactly this, with one substitution: the agent is Microsoft Excel. HCALC logistic fit: P Excel succeeds vs. human task length Excel succeeded on 19 of 23 tasks 80.6% weighted . The failures: it believes 1900 was a leap year a real bug, preserved deliberately for Lotus 1-2-3 compatibility ; the matrix inversion overflowed; the 2.5-million-row ledger exceeded the 1,048,576-row worksheet limit; and the customer-ranking run was scored zero after the human peripheral developed repetitive strain injury at row 14,203. The fitted curve crosses 80% at 390 minutes — 6 hours 30 minutes 95% CI: 18 seconds to unbounded; 12.7% of bootstrap resamples contain no failures at all, in which case the horizon is infinite . It crosses 50% at 54 working weeks. 80%-time horizon of frontier systems, 1985–2026 For context, I computed 80% horizons for frontier LLMs from METR's own published TH1.1 run data, using the same fitting code. The best system on the current plot, Claude Mythos Preview, sits around 3 hours at 80% reliability — METR reports it more than doubled the next-best model, and the next-best Claude Opus 4.6 computes to about 70 minutes. Excel beats the frontier by 2.2×. The LLM frontier's doubling time works out to roughly 4 months, consistent with what METR and the UK AISI report, which back-extrapolates to a predicted 1985 horizon of about 10−32 seconds. Excel's measured horizon exceeds trend by 36 orders of magnitude. Alternatively, the trend is fine and Excel's capability has simply been flat for 41 years — which, under this framework, means it is due. I will be honest: I am rattled. Before running HCALC, my probability of catastrophic outcomes from spreadsheet technology by 2035 was maybe 0.1%. It is now 5–10%. This capability was hiding in plain sight — installed on more than a billion devices, embedded in every bank, every hospital, every defense contractor — and nobody benchmarked it. We spent 2025 arguing over whether the frontier had crossed one hour or two, and the entire time a system with a six-and-a-half-hour horizon was sitting in the taskbar. I did not realize we already had these advanced technologies. If a capability can sit 36 orders of magnitude above trend for four decades without anyone noticing, the correct response to any capability chart is fear, and the correct response to the absence of a capability chart is more fear. I keep coming back to the Monte Carlo result: eleven months of human labor, 51 seconds of machine time. That ratio is not going to get smaller. Having slept on it, some concerns, in descending order of severity. Every item above is a live issue with the chart your feed re-litigates monthly. Through 2025, the frontier region of the METR plot — tasks of one to four hours — contained 14 samples https://shash42.substack.com/p/how-to-game-the-metr-plot , and the task topics are public, weighted toward cybersecurity CTFs and ML-engineering problems that labs openly train for; a lab can move its dot by upsampling those distributions, deliberately or by accident. Claude 3.7 Sonnet was assigned a 59-minute horizon while succeeding on roughly 60% of one-to-two-hour tasks, because it went 0-for on the 2–4 hour bucket and the logistic fit punished the whole curve for it. Shashwat Goel showed you can reconstruct the entire log-linear trend from aggregate accuracy plus the task-length distribution with a fixed slope — the individual task outcomes barely matter. METR's own limitations notes supply the rest: bootstrapped confidence intervals of roughly a factor of two in each direction, widening as the suite saturates; 50% and 80% horizons that are not independent estimates https://metr.org/notes/2026-01-22-time-horizon-limitations/ , because a two-parameter logistic cannot fit both ends of the curve; only 5 of 31 tasks over eight hours https://metr.org/blog/2026-1-29-time-horizon-1-1/ with measured rather than estimated human baselines; success rates that fall about eight points per unit of task “messiness”; and a standing notice that measurements above 16 hours are unreliable on the current task suite — which did not stop the discourse from treating a ≥16-hour point estimate for Mythos Preview as a fire alarm. To be clear about the target: this is not a case against METR. They publish their runs, their code, and their caveats, and that transparency is the only reason this parody was buildable in an afternoon; task-length horizons remain a better question than benchmark accuracy. It is a case against the inference pipeline downstream — the one where a dot moves inside a 14-sample region of a two-parameter curve fit, and timelines, investment theses, and p doom s all reprice by close of business. If a chart moves your worldview, first count the samples doing the moving. Mine had two. They were dice.