METR’s time horizon, certified to the last bit.

The Time Horizon 1.1 post of 29 January printed TH1.1 horizons for seven models. Against the May per-task file, one is the rounding of the certified horizon and six are not — by 3 to 12 % — and the site’s own May estimates moved by the same amounts. Nothing was mis-computed: runs were added between the post and the chart (the repository’s runs file of March already gives the May numbers to 2.2e-5), and the post is a fit on the January runs that no public file holds. A printed number without the file it came from cannot be re-decided; it can only be dated.

This page is a calibration. The same instrument is built to fit a time-horizon curve on tasks graded by an exact verifier — no answer key, no judge, no tolerance (the blind-spot, break-the-grader and lattice-claims environments) — against timed human baselines, and to state the 50 % horizon as an enclosure with its human-baseline provenance pinned. The pipeline from this machine’s own Inspect logs and baseline file to that fit is wired and runs at every build of the ledger; today it reports NO DATA: 1 baseline file(s) with 0 attempts, 18 tasks listed of which 0 have a human time, 0 frontier log(s) with 0 rollouts. When those counts are non-zero the fit is the one proved here on METR’s data, and nothing on this page will need to change for it to be trusted.

For a system card. The 50 % time horizon reported for each model on METR’s Time Horizon 1.1 suite was re-derived by an independent implementation of the published estimator (weighted L2-penalised logistic regression of task success on log₂ human minutes, λ = 10⁻⁵, inverse-root-family task weights) with the optimum certified by interval arithmetic: for all 23 models the fitted parameters are proved to lie in a box of radius below 10⁻¹⁰, the reported slope and intercept are the rounding of that box for 22 of 23 models (the remaining one differs by 0.001 in the intercept), and the reported point estimates of the horizon lie within 1.8e-4 (relative) of the certified value, consistent with optimiser tolerance. The reported bootstrap intervals contain the certified values in every case and were not re-derived. The post-2023 doubling time re-derives as 128.74 days against the reported 128.744. Evidence: the runs file at commit 52cb829 of METR/eval-analysis-public and the site’s task and benchmark result files fetched 2026-09-22, pinned by sha256 in this repository.

For a regulator. The headline capability number in this report — the length of task, in human working time, that a frontier model completes half the time — depends on a statistical fit whose correctness is usually taken on trust. We checked it without trusting it. Using METR’s own published data, we proved, in arithmetic that accounts for every rounding error, that each fit has exactly one best answer and computed a range narrower than a ten-billionth around it; every number METR published lands where that proof says it must, and the rate at which the horizon doubles re-derives from the same models as 128.7 days. What this does not establish: whether the tasks, the human timings or the success criteria are the right ones — those are METR’s choices and are outside what arithmetic can decide. What it does establish: that the trend line quoted to you is computed exactly as described from exactly the data shown, and that anyone can rerun the proof in two minutes from the public files.

For a post. METR’s time-horizon curve is the most-quoted graph in AI forecasting, and its points are fits nobody outside METR has checked. I checked them — not by refitting and eyeballing, but by proving each fit has one optimum and boxing it to 10⁻¹⁰. Every published number lands in its box or within a solver’s tolerance of it; the doubling time comes out at 128.7 days, the digit they print. The one thing that moved is the January post versus the May chart: six of seven horizons shifted by 3–12 % as runs were added, which is fine, and which you can only know because the files are public and pinned. The instrument that did this is built for a harder job: a time-horizon number on tasks graded by an exact verifier, with no judge in the loop. That number is next.