Milestones: mathematics and software

Axiom and the enormous theorem

❓ What did the swarm actually accomplish, and what did people and the proof checker contribute?

On October 26, 2026, Axiom reported a complete Lean formalization of the classification of finite simple groups, sometimes called the enormous theorem. The theorem classifies the indivisible building blocks of finite symmetry groups. The underlying human proof was spread across roughly 15,000 pages and more than 500 articles by about 100 mathematicians; it is not a theorem newly discovered by the swarm. Axiom says engineers and mathematicians directed swarms of dozens of agents over 24 days, producing about 43.1 million lines of Lean code, incorporating prior work including about 1.2 million lines from Qiuzhen-CFSG (Axiom, October 26, 2026).

Lean is a proof assistant: its checker verifies that formal deductions follow from formal definitions and assumptions. It does not independently establish that a formal statement captures what mathematicians intended. Axiom stresses that people must inspect the final statement and definitions, and check that a seemingly completed lemma does not quietly assume what still has to be proved. A rigorously checked conditional statement can be correct while failing to establish the target theorem.

The work began with a human-built proof map, existing Lean work, 108 milestones, and about 380 tasks. Lead agents decomposed and reviewed statements; others searched prior results or wrote proofs; agents claimed tasks through GitHub issues and reported in Slack. Mathematicians investigated obstructions and consulted group theorists, while engineers maintained the infrastructure. Early work had to be deleted and replanned after agents relied on unproved prerequisites. Verification became so expensive that engineers distributed cached builds across workers and parallelized checks. The cited report says these changes sped checking by orders of magnitude but does not supply enough measurements to estimate an independently reproducible rate.

Formalization revealed problems in published arguments, including 34 noteworthy deviations requiring resolution. Axiom describes a false intermediate assertion and a replacement route for an unbalanced-group argument, together with a new preservation result; it also notes a shorter alternative later found by its mathematicians. Whether the formal development and mathematical interpretation withstand further independent expert scrutiny remains an important follow-up; this report attributes completion to Axiom rather than claiming an independent audit has already been performed.

The insight is not that 43 million lines are inherently better than a shorter proof. It is that a network of partial results was connected to a precisely stated final theorem while a machine checked deductions. The swarm made the generation and coordination of candidate proofs much faster; the strong checker and human review addressed different parts of correctness.

Cursor's browser and SQLite experiments

❓ Did a swarm really build a database, and what was actually tested?

Cursor's July 20, 2026 study compared an earlier and a redesigned swarm on implementing SQLite functionality in Rust from an 835-page manual. Cursor withheld the original source code, test suites, SQLite binary, and internet access. It graded output with sqllogictest, a suite with millions of query cases comparing SQL results. The agents were not told the suite existed. Cursor also reports manually reviewing the runs for shortcuts (Cursor, July 2026).

At four hours the new configurations scored 73–85% against 11–77% for the old configurations; Cursor reports that every new configuration eventually passed its full held-out suite. In a Grok 4.5 comparison the new swarm reached 80% at four hours, while the old run was paused before two hours. The old run produced about 68,000 commits and over 70,000 merge conflicts, showing that activity can be churn, not productivity. The new run had fewer than 1,000 conflicts over the four hours. These are vendor-reported experiments, not a general law of agent performance.

Passing the suite does not establish complete SQLite equivalence, production readiness, resilience to crashes, transactional durability, security, or acceptable concurrency. The score is the fraction of that named suite passed, not a percentage of all SQLite features or all possible correct behavior. Different models were tested, and Cursor's informal single-model runs were not graded comparably; its results do not by themselves prove superiority over a well-tuned single-agent baseline.

The custom version-control system

❓ Why did Cursor replace Git, and does more commits mean more useful work?

Cursor says its earlier browser swarm peaked at roughly 1,000 Git commits per hour, while its new agent-oriented version-control system peaks around 1,000 commits per second. These are different systems and workloads, not a controlled speed benchmark proving Git is universally 3,600 times slower. Cursor says it wanted both throughput and direct control over where agent collisions are detected and resolved. It introduced a neutral agent to resolve merges, shared design decisions with compile-checked references, and a way to split overgrown files. Cursor's earlier browser effort was a proof of concept, not a polished browser (Cursor, July 2026).

A textual merge can still be semantically wrong. Two changes may merge cleanly while disagreeing about what a shared interface means. More commits per second can make this worse if verification and integration do not also improve. The same source's old swarm is a particularly useful warning: far higher activity coexisted with conflict and instability.

Economics of the SQLite comparison

❓ Does a swarm make engineering cheap, or merely trade expensive time for compute?

Cursor reported $1,339 for one Opus 4.8 planner / Composer 2.5 worker configuration and $10,565 for a GPT-5.5 planner-and-worker configuration. It reports workers used at least 69% of tokens, and over 90% in most runs. The results suggest that expensive reasoning can be concentrated in planning while cheaper workers execute well-specified tasks. They do not establish a universal 8-to-1 cost saving: the systems, model behavior, completion trajectories and quality evidence differ, and the article does not provide a complete accounting of engineering, infrastructure, review or operational risk. Pricing and model availability are time-specific.