Q2.5 2026 Timelines Update: Uplift and Revenue

Eli Lifland, Daniel Kokotajlo, and Brendan Halstead

Aug 16, 2026

Tl;dr: Our timelines haven’t changed much (they got slightly shorter) but our modeling and evidence base have noticeably improved, so we feel somewhat more confident.

Summary

We intend to regularly update our AI timelines forecasts as new evidence comes in and new analyses are done. Today’s “Q2” update was delayed by the crunch to publish AI 2040: Plan A, our domestic regulation blog post, and the time needed to implement and document changes to our model.

The original AI Futures Model predicted when Automated Coder (AC), an AI for which the leading AI company would rather fire its human software engineers than forego AI usage for coding, would happen using METR’s measurements of coding time horizon. (More precisely, time horizon anchors are used to set the effective compute required for AC.) While serviceable, this method has huge weaknesses, including (a) it’s unclear what time horizon corresponds to AC (it’s even unclear whether any finite value would) (b) people strongly disagree about the extent to which we should expect the time horizon trend to be superexponential as a function of effective compute, in a way that can lead to vastly different predictions.

So we’ve been on the lookout for other methods for setting the effective compute required for AC, and now we have two candidates: coding uplift (i.e., how much of a speedup AIs are providing to software engineers at AGI companies) and revenue. Coding uplift is our favorite method: the basic idea is to estimate the doubling time of the quantity (uplift - 1) and extrapolate that until AC-level uplift is reached. The way we anchor the model using uplift-relevant estimates is a bit complex, so we first explain a simpler 3-parameter uplift model that gives similar results. With coding uplift, the value corresponding to AC is much less uncertain than with time horizons, and while we also expect coding uplift to be somewhat superexponential this isn’t nearly as important as with time horizons.

Surprisingly, all 3 methods predict quite similar AC arrival dates.1 We take this to be a somewhat encouraging sign about the robustness of our forecasts, though we are still very uncertain.

You can explore the uplift-anchored version of the model at aifuturesmodel.com and the other options for AC forecasting via the dropdown at the top of the second graph.

Each author assigned weights to the 3 AC anchoring methods which the model aggregates into an overall forecast. We also re-evaluated AI 2027’s predictions; reality seems to be going about 70-90% as fast as AI 2027 predicted.

Incorporating all of the above, our latest all-things-considered timelines forecasts: (link)

Here’s how our forecasts have shifted recently:

We describe in the appendix:

How our AGI forecasts have changed since 2021.

We changed the modeling to take into account that training is needed to apply software improvements, which reduces the chance of very fast takeoffs.

Some authors made minor adjustments to some other parameters, and we clarify that our forecasts are conditional on going as fast as is technically feasible.

We made some minor changes to the model and website code.

A 3-parameter uplift model for predicting when Automated Coder will arrive

A simple method to predict the AC arrival date is to assume that (coding uplift - 1) grows exponentially. We think that this is the best simple model for predicting when AC will arrive.

Specifically, this model takes as input 3 parameters, for which we list Daniel’s median estimates:

Present day coding uplift, i.e. the speedup factor due to AI assistance: 2x. Daniel thinks 1.04x is something like a lower bound given the METR study which found 1.04x - 1.2x uplift, with METR thinking that these numbers were biased downward due to selection effects (people were less likely to participate in the study if they thought AI would be useful to them.) Otherwise, he’s integrating various sources of evidence including the Apr 2026 Anthropic internal survey having a geometric mean of 4x, and a private estimate of 1.7x AI R&D labor uplift by Ryan Greenblatt (which was an estimate for AI R&D labor as a whole, so presumably coding-only would be higher).

Present day doubling time of the quantity (uplift-1): 5 months. According to Anthropic employee surveys, coding uplift has gone from 1.25x to 4x in 7 months.2 This would be a ~2 month uplift doubling time, but correcting for Mythos Preview being above the long-term Anthropic ECI trend gives us a ~3.5 month doubling time.3

Now, probably their employees are biased towards overestimating coding uplift. But unless the bias has been significantly increasing over time, that’s still more than three doublings of uplift-1 in less than a year – a 3.6 month doubling time! Daniel’s median is longer, 5 months, because he’s partly deferring to the opinions of other researchers he respects (Eli and Ryan) whose subjective sense is that the doubling time is longer.

Uplift corresponding to AC: 20x. The full AI Futures Model says 32x in the median case, but we expect the true uplift to be a little lower because the model doesn’t account that AIs can be used to accomplish coding tasks less efficiently than humans.

Comparing Daniel’s median estimates with Eli and Brendan’s:

This simple model extrapolates the uplift trend (assuming the doubling time stays constant, i.e. the trend is exponential)4 and sees when it reaches the uplift corresponding to AC.

What does this method say? See ac-arrival.vercel.app for a vibe-coded app in which you can play around with the simple extrapolation.

See below for a more complicated version that uses present day uplift and uplift doubling times as anchors for setting the behavior of the full AI Futures Model. Factors that are accounted for in the full model are:

The (uplift-1) doubling time decreases over time because the percentage of coding tasks automated is modeled as a logistic curve with an asymptote above 1. (If the asymptote was at exactly 1, then that would mean there would always be some important coding tasks that humans do better than AIs, which we think is unrealistic; eventually AIs will be able to do all of them.) However, even in the full model the trend is approximately exponential when far from AC.

Changes in the effective compute growth rate caused by AI R&D automation, human labor trends, and compute trends.

The full model doesn’t have uplift at AC set as a parameter, instead it is inferred from model behavior.

Adding uplift and revenue anchors to the AI Futures Model

We’ll now discuss how uplift and revenue estimates can be used to estimate the effective compute required for AC by anchoring the AI Futures Model.

Our overall forecast is made by using each method separately and then aggregating the results via a weighted mixture. You can explore the uplift-anchored version of the model at aifuturesmodel.com and the revenue (and time horizon) option via the dropdown at the top of the second graph.

We give the following weights:

We give the most weight to uplift because (a) the value corresponding to AC is more clear than for revenue or time horizon and (b) the trajectory of (uplift - 1) seems closer to exponential in log(effective compute) than for time horizon. The main advantage of time horizon relative to uplift is that it’s more measurable, and the main advantage relative to revenue is that it’s a more direct measurement of coding capabilities.

Uplift

Our model already issues predictions about coding uplift, so we aren’t fitting an entirely new function and AC requirement like for the other two methods.

There is a module in the AI Futures Model (AIFM) which aggregates human labor and AI agents to produce an estimated “aggregate coding labor” (and therefore an estimated coding uplift) at each capability level. This module is generally calibrated by three degrees of freedom:

One is pinned down by the uplift at present day

Another parameter sets the “shape” of the distribution of coding task difficulties (e.g. is there a long tail of capability levels where AIs can’t yet do all tasks, despite having been able to do most tasks at much lower capability? Or does automation happen more “all at once” in capability space?)

The last degree of freedom is the capability level (in effective compute or ECI) where the definition of AC actually becomes satisfied, that is, when AIs alone can do the full spectrum of tasks so that you’d rather hire only AIs than only humans.

In time horizon and revenue mode, we use one of those trends to choose the capability level pinning down the third degree of freedom. In uplift mode, we don’t directly specify the capability level corresponding to AC, and instead we constrain the remaining degree of freedom by specifying the rate at which coding uplift is increasing today (specifically, the doubling time of uplift - 1). With the automation module calibrated, we can then read off the capability level corresponding to the AC definition, and therefore the AC date.

Revenue

We fit a function from AI capabilities (operationalized as effective compute or ECI) to leading AI company annualized revenue (specifically, the leading AI model developer’s revenue; so not including Nvidia). In particular, we fit an exponential function from ECI to annualized revenue (equivalent in our model to an exponential function from log(effective compute) to annualized revenue). We extrapolate the function into the future, and make guesses about which level of AI company revenue would correspond to having just achieved the AC milestone.

We estimate the following median parameters:

Modeling annualized revenue as an exponential function of ECI is a bit more sophisticated than modeling it as a function of time; it allows us to incorporate effects like a slowdown in datacenter growth or a feedback loop from AI R&D automation. Empirically, revenue has grown by 10x for every 15 ECI points so far. However, this method doesn’t take into account various other drivers of revenue growth besides capabilities (such as % of total compute allocated to inference and inference margins). It also doesn’t take into account that even holding those factors constant, revenue might not be an exponential function of ECI.

We try to intuitively take these factors into account by our choice of parameter values — even though Anthropic’s annualized revenue has grown 10x/yr for several years, we think it’ll slow down soon, and use 5-7x/yr as our median current growth rate.

Update to the grading of AI 2027’s predictions

Comparing the AI 2027 pace of progress to reality

We’ve updated our assessment of how the pace of AI progress has compared to AI 2027. Depending on what metrics you include and what aggregation method you use, reality seems to be going at roughly 70-90% the speed of AI 2027. That’s the quantitative assessment. The qualitative assessment will be discussed in the next section.

If progress were to continue at 75% of the pace of AI 2027, Automated Coder would be reached in mid-2027.5

Part of the reason that the relative uplift pace of progress is so much lower than the others is that since publication, we’ve revised our estimates downward for what AI software R&D uplift was at the beginning of AI 2027. This is reflecting a real way that we estimate reality is behind schedule, but it makes the “pace” of progress framing not as natural as the others.

As for the public salience metric, which is our biggest predictive error, we wonder if we should have picked a better operationalization. AI does seem much more salient today than it was a year ago, even if that particular survey isn’t showing any progress.

A few minor methodological changes we’ve made since our previous evaluation:

We removed old predictions from the evaluation, in particular mid-2025 benchmark predictions and late-2025 compute predictions. We also didn’t evaluate

[truncated for AI cost control]