*About 6x slower in the median case, with an 80% confidence interval of 3.5x to 8x. *
Define the "R&D compute" (in, say, H100-equivalents) of an AGI company at a given time to be the total compute in use across the following categories:
With less R&D compute, the company would need to make cuts across these categories. For now, we'll assume they maintain the same allocation across the three areas, that is, we'll assume they achieve the reduction in the total via a reduction to each category.
The capability level of your best AI model is represented by its effective training compute, . is a stock, with units of "2025-FLOP". evolves according to
where is training system performance (a flow, units: FLOP/yr) and is software efficiency (units: 2025-FLOP per FLOP). We will call this quantity effective training system performance.
Training system performance and software efficiency tend to grow exponentially over time, so the "rate of AI progress" will be operationalized as the relative growth rate of (i.e. the time derivative of , which equals ). We will use the symbol for this.
Huh? Why this model?
Other models of AI takeoff (the AI Futures Model, Tom Davidson's FTM, Epoch AI's GATE) compose effective compute multiplicatively from two stocks:
where is cumulative training compute (a stock, units: FLOP, satisfying ). In other words, they apply today's software efficiency to every FLOP ever spent on training, "pulling outside the integral". Our formulation instead applies to the flow: , so . An algorithmic improvement raises the value of each FLOP spent from now on, but never retroactively upgrades FLOP spent under older algorithms.
A large, sudden compute reduction is precisely where the formulations come apart. Physically, the cut is a cut to flows: the rates at which FLOP are spent on experiments, agents, and training all drop by 10x. The multiplicative model has no training flow among its state variables, only the stock $C$, so the cut has to be translated into a statement about $C$. There are two natural translations, and neither is good:
The remaining simplification is treating AI progress as a single continuous training run that has been underway since the beginning of time. (Mathematically, the integral defining $E$ runs from minus infinity to the present.) In reality, frontier training runs sometimes start from scratch, have different lengths, and may only be underway during parts of the year. We think this still captures the dynamics relevant to compute reductions, but it directionally favors the compute-reduced project: some capabilities may require architectural changes or otherwise require starting from scratch, i.e. re-accumulating $E$ from zero, which is far more costly at a reduced flow, and this model assumes you never need to do this. In other words, if anything, a real 10x cut probably buys somewhat more slowdown than the model estimates.
Software improves via the semi-endogenous growth law
That is, the relative growth rate of software efficiency is research effort divided by a difficulty term that rises with the software level already achieved. parameterizes how much harder further improvements get as climbs (the "fishing out" of ideas). (Human and AI labor also enter research effort, but experiment compute carries almost all of the weight in the relevant regime, and the labor cut matters less and less as automation saturates.)
We are going to compare two quantities:
When we cut R&D compute by in this model, since assumed proportional reductions across all categories, the immediate effect is a reduction in , and therefore also a reduction in the rate of AI progress .
What happens after that? To figure this out, we can look at how changes over time. Differentiating,
This term equals the relative growth rate of , , or the growth rate of effective training system performance . We will call the growth rate of effective training system performance . The equation above then becomes
(This has the form of the "logistic differential equation", with carrying capacity .) Qualitatively, it says that when effective training system performance grows faster than capabilities (), then the growth rate of capabilities increases (). Conversely, when capabilities are growing faster than ETSP is, then capabilities growth will slow.
Hence, after falls by , the subtraction on the right hand side is positive, meaning that is increasing. That is, the rate of capabilities progress will initially fall by , then pop back up again, until effective compute is growing at the same rate as software efficiency. It will continue to increase so long as exceeds , gradually approaching the fixed point where and .
If training system performance (the raw hardware) remains constant after the reduction, then is just the growth rate of software efficiency, determined by experiment compute and AI labor, which today proceeds at perhaps 1 OOM per year. With less compute for experiments, and less compute to run automated researchers, the growth rate falls, but probably by less than . Say it falls by some factor with . Now we have to determine how the rest of takeoff goes. Both trajectories have to traverse the same interval of capability, from the level at the cut to whatever level counts as the end of takeoff, and the time this takes is
In steady state , so if the slowed trajectory's is lower at every capability level (with the same N throughout), the integrand is larger everywhere and the total time is longer. So we want to show that the ratio of the two trajectories' software growth rates at matched capability is constant, and to find it.
Dividing the default trajectory's software law of motion by that of the reduced-compute trajectory yields
where we are making the approximation that research effort exhibits constant elasticity to experiment compute over the relevant range. [1] Intuitively, the factor is the direct slowdown at that capability level, and the second factor adjusts for the increased "fishing out" effect associated with the greater software content of the trajectory with reduced compute.
Now we determine his determines how much more software the reduced-compute trajectory holds. At the fixed point , we have . Taking logs,
We can write this identity once for each trajectory at the same , and subtract:
Rearranging yields
Hence the software ratio (at steady state) is indeed independent of capability level. By substituting, finally we can solve for :
This makes sense in the extreme cases:
After modifying the AI Futures Model to use the continuous training run ODE described above, I simulated the effect of compute reductions while sampling from our parameter distributions. The various approximations involved in the derivation held relatively well:
The slowdown factor does not depend greatly on the specific capability level at which the reduction occurs. Here, with the relevant parameters held fixed at our median estimates, you can see that N ranges from 5.2 to around 6:
There is significant uncertainty in our estimates of N, mostly driven by our uncertainty about the current rate of software progress. The main other important parameter determining N in the AI Futures Model is the current-day software progress elasticity to experiment compute, which we estimated by polling AI researchers.
In the AI Futures Model this is approximately true, since during takeoff, research effort is highly bottlenecked on experiment compute.