Evaluating Long-Horizon Agent Capabilities in Large Models: From Prototype Systems to Formal Verification
Two recent experiments show large models coordinating thousands of sub-agents over multi-day horizons to ship a bootable OS prototype and a machine-checkable formalization of a known theorem. This article explains what those results actually measure, why formal verification is a useful rigor benchmark, why the same base model can ship as very different products depending on safety gating and access, and how to evaluate long-running agent work against machine-checkable acceptance, collaboration structure, full cost, and controllable failure modes.
Three signals that long-horizon capability is moving
Two recent industry results give new evidence on whether large models can independently complete long-cycle engineering work.
In one experiment, a model started from an empty directory, coordinated more than a thousand sub-agents, and continuously wrote, tested, and reviewed code. The result was a prototype operating system that boots on an ordinary laptop, covering a kernel, disk and keyboard drivers, networking, persistent file storage, a windowing system, a login screen, and an installer.
In another, about a thousand agents running an earlier model version reproduced, in roughly thirty hours, a machine-checkable formalization of a well-known theorem whose existing proof had already been published. The comparable human formalization effort had taken eleven days.
What these results share is not a single-point score jump, but the ability to decompose, execute, and integrate work across multi-day timescales: split a large goal into executable subtasks, keep context consistent over a long span, and return an artifact that can be inspected as a whole.
The verification boundaries still need a sober reading. “It boots” for the prototype does not include long-term stability or compatibility testing. The formalization target is an existing proof: humans had already laid the argument; the model translated informal reasoning into a machine-checkable form rather than producing an original proof. Each result answers a specific question. Using them for model selection requires reading the conditions under which they hold.
Why a ~30-hour formalization run matters
Formal proof means writing a mathematical argument so that every step can be checked automatically by a proof assistant. The value is eliminating human slips: a paper-style proof can hide gaps; a formalized proof can be verified line by line by a computer.
Typical properties of this work:
- Very fine grain: a compact-looking theorem can expand into tens of thousands of lemmas and intermediate steps.
- Strict fault tolerance: a type mismatch or missing hypothesis fails the checker and forces backtracking.
- Cost concentrated in translation and debugging, not in “understanding the idea.”
Speedups here mainly reflect long-context memory, error localization, and autonomous backtracking. That resembles code generation, but the acceptance criterion is more objective: pass the checker or not. There is little room for subjective scoring, which makes it a useful benchmark for model rigor.
Same underlying model is not the same product: capability vs. safety boundaries
A selection detail that is easy to miss: different product forms of the same model family can have very different usable scope.
A common pattern is to share one base model and then differentiate product lines with safety filters and access rules. Consumer-facing versions often block high-risk cybersecurity and biosecurity work: penetration testing, exploit generation, binary vulnerability analysis, and much research-grade biology may be refused and handed to a less-restricted model. Versions available only to verified organizations may not carry the same filters; high scores on official safety benchmarks (red-team cybersecurity, known-vulnerability reproduction, de novo protein design, and similar) are often attached to that restricted-access form.
That creates a selection trap: leaderboard scores may correspond to a product you cannot actually use. Choosing only on benchmarks, without checking the safety envelope and access eligibility of your account, produces a capability gap at deployment.
A practical record should track three dimensions:
Model selection record├── Capability: task benchmark scores, long-task stability, context length├── Safety: which domains are blocked, which model answers after a refuse, intercept-rate trends└── Access: product form available to the current account, org verification status, quotas and billing
Safety policy itself also changes. Official tests have shown a newer version cutting total intercepts by more than half versus the prior generation, with a larger drop in cybersecurity blocks and a milder change in biology. Fewer intercepts means fewer false refusals, but whether a high-risk task is allowed still has to be confirmed domain by domain. “Fewer blocks” does not mean “everything is allowed.”
A practical evaluation frame for long-running delivery
To judge whether a model can take over a real project, start with four questions:
Is acceptance machine-checkable? A bootable prototype or a proof that passes a checker is objective. If acceptance is vague (“it should feel good”), long-horizon agent output is hard to ship without humans defining checkpoints.
Is the collaboration structure clear? Thousand-agent coordination depends on task decomposition and interface contracts. Human teams need architects and code review; agent teams need module boundaries, review rules, and merge policy. Treat the system as an automated colleague, not a one-click machine.
Have you counted the full ledger? Long jobs mean many inference calls, test runs, and retries. Cost-effectiveness should include tokens, wall-clock time, and failure-retry cost versus a fully human or human-in-the-loop plan—not unit price alone.
Are failure modes controllable? Long-horizon failure is often directional drift, not a single error. Stage gates (like CI quality gates) should validate intermediate artifacts so mistakes do not compound past recovery.
Closing
Progress in long-horizon agents is real: empty directory to bootable system, math paper to machine-checked formal proof, both mark a shift from answering questions to delivering artifacts. There is still a clear gap between “it boots” and “production-ready,” and between “reproducing a known proof” and original research. For enterprise buyers, rational selection is not chasing leaderboard peaks. It is lining up capability, safety posture, access eligibility, and full cost against your own acceptance criteria. Those four dimensions together make the judgment hold.
