The newest LLMs, freshest first

New does not mean better, and the first two weeks after a launch are the least reliable time to evaluate any model. Launch-day benchmark numbers come from the lab, using prompting and scaffolding it chose, with no independent replication yet. Independent harnesses usually report lower figures a few weeks later, and that gap is normal rather than dishonest.

Serving conditions also shift after release. Providers tune quantisation, batching and routing under real load, so the model available on day one is not always identical in behaviour to the one available a month later. Independently-run indices measured against production endpoints are more trustworthy than launch-post tables for exactly this reason.

There is a real advantage to newness, though: training cutoffs. A recently trained model knows about libraries, APIs and events that an older one does not, which matters enormously for coding against fast-moving frameworks. If your work involves recent tooling, recency can outweigh a few benchmark points.

The failure mode to avoid is chasing every release. Migration has costs — prompts that were tuned for one model rarely transfer cleanly, tool-calling behaviour shifts, and output formatting changes in ways that break downstream parsing. A sensible cadence is to evaluate new frontier releases against your own test set, and only migrate when the improvement is clearly larger than the switching cost.

This page orders models by public release date so you can see how fresh the current leader actually is. Rumoured and unreleased models are tracked separately and marked as such — those entries reflect credible public reporting, not confirmed specifications.

More on how these numbers are produced in the methodology and what each evaluation measures in the benchmark guide. Spotted a score that disagrees with its source? Tell us.