Sources of improvement

Almost all the evidence points to very fast software progress: each year, the training compute needed to get to the same capability declines several times — possibly even ten times or more.

Epoch's synthesis of what is known about software progress, with data quality improvements plausibly the largest and least measured contributor — a direct update to the compute-vs-algorithms decomposition, and a complication for software-explosion models (1.5.2).

Without diverse, high-quality environments and tasks to train on, throwing more compute at RL risks wasting much of it.

A grounded survey of the RL-environments supply chain — who builds them, what they cost, and why environment quality rather than raw compute is emerging as the bottleneck for RL-driven progress.

if most of the spending is exploration rather than execution, then a competitor who learns what works from the frontier could replicate the results for a fraction of the original cost.

Final training runs are only ~10–23% of lab R&D compute — experimentation, synthetic data generation, and failed runs are where the compute input actually goes, with implications for fast-follower competition.

I think compute-poor labs probably can't fully make up for their 10x compute disadvantage to compete at the frontier.

Whether algorithmic innovation, replication, or distillation can substitute for compute: only distillation meaningfully narrows the gap — a direct answer to which input dominates and who can compete.