Most frontier AI is just more compute

What MIT found

A March 2026 study from MIT’s Computer Science and Artificial Intelligence Laboratory analysed training and benchmark data from 809 large language models released between 2022 and 2025. Using statistical analysis, the team disentangled three things: raw compute, shared algorithmic progress across the field, and company-specific advantages.

The headline result: at the frontier, 80 to 90% of model performance is explained by scale — by how many GPUs a lab can afford to run, for how long, on how much data. It is remarkable how much of the progress at the frontier of these models is driven by just having more GPUs and running them for longer… It’s not some special recipe that firms have, where they know how to do something fundamentally more efficiently. It’s scale.

Below the frontier, the picture changes. Off the top tier, proprietary techniques and clever efficiency work matter considerably more — and some developers are genuinely better at squeezing more from every bit of compute. Microsoft, for example, stood out for unusually efficient small models.

What that means for the labs

If the frontier advantage is mostly dollars, then it is a fragile lead. If everybody has access to the same kind of hardware and can scale up in the same ways, leads may be more fragile than people think. The implication is geopolitical as well as commercial: with roughly comparable hardware access, US and Chinese labs should converge over time — which is broadly what the open-weight release calendar of 2026 has been showing (How China caught up on frontier AI).

The same logic applies inside the open-weights market. As long as a frontier model’s edge is we can afford more compute than you, the gap closes the moment an open lab matches the budget. Kimi’s K3 closes in on the frontier and Open weights just caught the coding frontier look less like flukes under this lens — they look like the predictable result of catching up on the one thing that matters most at the top.

The 40x surprise

The study’s second striking result is variation within a single company. The same developer, using comparable methods, can produce models that differ in compute efficiency by a factor of about 40. Thompson’s analogy for the unpredictability: It’s a bit like baking: even if the average of your cakes is great, sometimes one just doesn’t rise right.

Two implications follow. The first is reassuring: training is still an art, not a clean optimisation, and even the big labs cannot reliably reproduce their own best runs. The second is harder for them — if their internal hit rate is that variable, published benchmark numbers reflect lucky runs as much as underlying capability.

The agent angle

This is the seam Dana Blankenhorn’s February analysis of Peter Steinberger’s move to OpenAI pulled at. Blankenhorn’s argument: the durable moat in AI is shifting from language models — cathedrals, expensive to build — to agents — bazaars, expensive to integrate. Steinberger’s open-source agent project, OpenClaw, is, in Blankenhorn’s telling, what OpenAI is paying a reported nine-figure package for, on the view that orchestration code around the model is the harder thing to replicate.

The MIT result sits next to that comfortably. If the model itself is mostly a function of compute, the durable value sits in the orchestration, the data plumbing and the workflows bolted around it.

80–90%of frontier AI performance is explained by compute alone — not by proprietary techniques

What to do with this afternoon

The MIT finding carries a small-team lesson. If the frontier model you pay $20 a month for is doing its job mainly because its lab can afford more chips, then your edge cannot come from picking a cleverer model. It has to come from the data, the workflow and the orchestration you build around it. None of those are secrets either — but they are things your competitors will not copy in an afternoon, which is more than you can say for swapping from one frontier model to another.

If you want to test the thesis yourself this afternoon:

• Pick one job you currently run through a frontier API — a classifier, a draft-email helper, a query rewriter. Something modest.
• Replace it with a small, efficient open model on your own kit. Microsoft’s small-model efficiency is the proof point at scale; locally, Gemma 4 E2B: three jobs on 4 GB and A tiny local model can sort tickets are realistic starters on commodity hardware.
• Measure it on your own data, not a benchmark. If the small model does the job at a tenth of the cost, the frontier API was never the moat — your data was.

The aim is not to ditch frontier models wholesale. It is to notice, carefully, which parts of your stack actually depend on frontier capability and which depend on you. The MIT study suggests the second category is much larger than the marketing implies.