A 1996 Pentium shows how much chess progress came from software

Could a commodity computer from 1996 have beaten Garry Kasparov with today’s chess software? Nicholas Carlini’s answer is an emphatic yes. He ported Stockfish to a 200 MHz Pentium Pro with 64MB of RAM and estimates its strength at 3300 Elo at classical time controls, well beyond any human.

The experiment separates two kinds of progress that are usually bundled together: hardware that analyses more positions and software that selects and evaluates positions more effectively.

Algorithmic gains dominate

Carlini estimates that 720 of 1,335 Elo gains can be attributed to better programming rather than faster hardware. He tested both a modernised version of the 1996 Crafty engine and a Stockfish port adapted to 32-bit arithmetic and severe memory constraints.

The tuned Stockfish port reached 3,180 ± 80 Elo at 30 seconds per move before extrapolation to classical controls. In a 100-game match, a modern engine on the Pentium Pro won 78, drew 17 and lost five against the 1996 Crafty engine running on modern hardware.

The port is an engineering story too

The machine boots from a floppy and exposes chess positions through a custom HTTP service. Carlini is unusually transparent about using language models to implement the supporting code while writing the article himself.

That detail adds a modern layer to the experiment. Models helped with the mechanical work of adapting software to an old platform, but the meaningful result comes from measurement, tournament design and decades of accumulated engine research.

A broader lesson for AI evaluation

Benchmarks often reward the latest hardware and largest systems without separating implementation quality. This experiment is a reminder to ask how much improvement comes from scale and how much comes from search, representation, evaluation and tuning.

It also cautions against dismissing older compute as useless. Constraints can make algorithmic quality visible, and efficient implementations can deliver more capability than a simple hardware comparison implies.

The editorial lens

AI announcements arrive with competing claims about quality, openness and cost, but those properties are not interchangeable. A model that performs well in a controlled demonstration may behave differently with unfamiliar data, tool permissions, long contexts or production latency requirements. Open-weight releases add further questions about licensing, deployment responsibility and the ability of smaller teams to verify what they run.

A useful evaluation starts with the intended job and the cost of being wrong. Build a small set containing ordinary cases, difficult cases and known traps, then record the model version, prompt, reasoning settings, latency and price. Compare accepted outputs rather than raw generations, because discarded work and human correction are part of the system cost. For open weights, also check hardware requirements, quantisation, licensing, security updates and provenance. For hosted models, review retention, privacy, rate limits and incident handling. That turns a launch claim into a reproducible engineering input.

A compressed source summary cannot carry every operational detail. It may omit rollout timing, benchmark construction, eligibility, dependencies or conflicting results. That does not make the source wrong; it defines the limit of what the summary alone proves. Treat the initial report as a claim to be tested rather than a universal outcome. Check availability and version details for releases, reproducibility for research, and delivered usage for business claims. Where possible, run a small reversible evaluation and keep its measurements. Corrections and follow-up reporting can materially change the interpretation, especially when the underlying technology, pricing or policy is moving quickly. This distinction between a publisher’s evidence and its broader applicability is essential to responsible technical coverage.

Read Carlini’s experiments, code notes and Elo breakdown.