Examining AI Swarm Efficiency with the AI Futures Model

I've been playing around with the AI Futures Model (which informed AI 2027 and AI 2040) in order to better understand how AI swarms will reshape AI progress.

In particular, I've been interested in how parallel agent efficiency might increase capabilities and shorten timelines, and to be very particular, I've been interested in the parameter λ. To quote Toby Ord in Swarm Scaling:

λ is a parameter measuring how parallelisable the task is. They call it the ‘stepping on toes’ parameter.[1] If λ = 1, you have a perfectly parallelisable task, with no stepping on toes and no efficiency penalty. But in reality λ is usually between 0 and 1 — allowing more people to help, but with diminishing returns. For example, if λ = 0.5 then 100 people working together get as much done as 1 person working for 100 = 10 times as long.

λ is a parameter measuring how parallelisable the task is. They call it the ‘stepping on toes’ parameter.[1] If λ = 1, you have a perfectly parallelisable task, with no stepping on toes and no efficiency penalty. But in reality λ is usually between 0 and 1 — allowing more people to help, but with diminishing returns. For example, if λ = 0.5 then 100 people working together get as much done as 1 person working for 100 = 10 times as long.

In other words, λ is the common-sense notion that doubling the size of your project's team doesn't get the project done twice as fast. There are limits to how useful it is to keep throwing more people, or more AI agents, at a problem. At λ = 0.5, output scales with the square root of the number of people/agents working:

λ is explicitly modeled in the AI Futures Model, and you can find it under Advanced Settings → Advanced Parameters → Coding Automation → Coding Labor Parallelization Penalty (λ). It defaults to 0.5, and can be set between 0 and 1.[2]

Changing it from 0.3 to 0.8 can increase effective compute by nearly 100x! Even just 0.50 to 0.65 is ~4x effective compute at 10k agents.

And we have reason to think that, with OpenAI and Anthropic now training models to message each other and cooperate more efficiently, λ is more like 0.65 nowadays.[3]

So what happens if we plug that into the AI Futures Model? You'd expect that, if you increased λ from 0.50 to 0.65,[4] timelines would shorten, right?

Okay so what's going on with the AI Futures Model? Is there some unintuitive counterbalancing effect, such that organized AI swarms really would make AI capabilities progress slower?

Constraining the first-order effects of λ through other parameters.

Using λ to calibrate other parameters, such that changing it induces side effects.

The first-order shortening effects are then overwhelmed by second-order lengthening side effects. The end result is that increasing λ in the AI Futures Model mostly lengthens timelines, even though intuitively it shouldn't.

Now, to be clear, the AI Futures Model is pretty robust overall. It's just very complex! The website version allows you to vary ~40 parameters besides λ, most of them with fine-grained sliders, such that the total possible combinations of parameters comes out to something like 10^104. And the only reason I can even dissect the model in detail is because the AI Futures project not only released an interactive web version of their model, not only gave in-depth explanations of how their model works alongside that, not only wrote another 100+ pages of supplementary material on how they reasoned about it, but also open-sourced their code.

But I think the backwards effects of increasing λ here make an interesting test case in understanding how complex modeling the future of AI is, and the kinds of limitations you can run into. It's one I've been nerd-sniped with, anyway. If learning the details doesn't strike your fancy, feel free to skip ahead to "Modifying the AI Futures Model" to see what changes to the model I choose to make, and how they affect timelines more intuitively when increasing λ from 0.50 to 0.65.

For the rest of you: let's dive into what the heck is going on with λ in the AI Futures Model.

Might the effect we saw with λ = 0.50 vs. 0.65 be an outlier result? No:

Holding the model's default presets equal, increasing λ consistently lengthens timelines. The date specified for the Automated Coder (AC) and for ASI increases,[5] and the "takeoff" time between AC and ASI increases (that's the gap between the blue and orange lines).

Now, the AI Futures Model actually comes with three different presets, one from Daniel Kokotajlo, one from Eli Lifland, and one from Brendan Halstead. But all of these show the same effect, just at different intensities:

But fun fact, the AI Futures Model also offers three different "AC Anchors", where each anchor is a different way of estimating how much "effective compute" (raw compute x algorithmic progress, roughly) is necessary to develop an Automated Coder. These are:

Coding Uplift: judges AC to have been reached when 100% of coding tasks can be done by AI. This is the default.[6]

Time Horizon: judges AC to have been reached when the METR time horizon for a frontier model reaches 80% accuracy at:[7]Daniel: 1-year tasks.[8]Eli: 125-year tasks.Brendan: 125-year tasks.[9]

Daniel: 1-year tasks.[8]

Eli: 125-year tasks.

Brendan: 125-year tasks.[9]

Revenue: judges AC to have been reached when the leading lab's revenue hits:[10]Daniel: $1T/year.Eli: $7T/year.Brendan: $3T/year.

Daniel: $1T/year.

Brendan: $3T/year.

How are these alternative anchors[11] affected by increasing λ?[12]

The Time Horizon and Revenue anchors have intuitive responses to λ! Increasing λ decreases the time to the Automated Coder for them. Now, it still unexpectedly lengthens time to ASI,[13] but naturally the "AC anchor" setting mostly affects time to AC. We'll come back to takeoff/ASI later.

So, what's going on with time to AC and the three AC anchors?

Well, one thing we can see is that "time to AC" (the blue line) is actually pretty flat for the Time Horizon and Revenue anchors. In other words, changing λ has a limited effect under those anchors.

And if you think about it, it makes sense that Coding Uplift is most affected by λ. That anchor requires predicting how much benefit parallel agents bring to coding tasks. In contrast, the Time Horizon anchor is more about how well a single agent can complete very difficult tasks, and the Revenue anchor is more about how much of the economy is being automated by AI.

...did that make sense? Well, it shouldn't have! That explanation is totally wrong! Sorry to mess with you, but the above paragraph was my own initial instinct, so you're just going through what I went through. It turns out the effects here are more arcane, and we'll get into them in the next section. But I do think there's a lesson there: it's not always safe to try to navigate the map via your instincts about the territory.

Anyway, now that we've established[14]—under the Coding Uplift anchor for time to AC, under all anchors for takeoff to ASI—that λ reliably lengthens timelines in the AI Futures Model, let's try to understand why.

A parameter called "Serial coding uplift as of Aug 2026", which defaults to 2x.[15][16]

A parameter called "Infinite Coding Labor Asymptote", which defaults to 15x.[17]

The first has more to do with the Coding Uplift anchor and its time to AC. The latter covers all anchors and deals with takeoff to ASI from AC.

The AI Futures Model, under the Coding Uplift anchor, builds its estimates of AI coding speedup ("uplift") on the default claim that the uplift is 2x as of Aug '26.[18] That is, using AI speeds up coding productivity 2x overall.

That Serial Coding Uplift parameter is then used to backcalculate[19] a bunch of other values, including the fraction of coding tasks that AI does today. Automated Coder (AC) is defined as the point at which that fraction hits 100%, so changing the Aug '26 AI uplift parameter changes how close we are to AC today.

The AI coding uplift is modeled in serial time. Roughly speaking, it compares one software engineer without AI to one software engineer with one AI agent. Real-world parallel agents are converted into an equivalent serial agent using λ. The logic goes as follows:Speedup (coding uplift) is defined using , with N as the # of parallel agents raised to the power of λ, the "stepping on toes" penalty exponent.With λ = 0.50 and N = 4 parallel agents: x speedupBut we're backcalculating with S as a given, so restate as: where S = 2.With λ = 0.50: agentsWith λ = 0.65: agentsIn other words, increasing λ decreases the expected number of parallel agents necessary to do one serial agent's work. That, on its own, makes sense. The better the parallel agents work together, the fewer you need for equivalent performance.

Speedup (coding uplift) is defined using , with N as the # of parallel agents raised to the power of λ, the "stepping on toes" penalty exponent.With λ = 0.50 and N = 4 parallel agents: x speedup

With λ = 0.50 and N = 4 parallel agents: x speedup

But we're backcalculating with S as a given, so restate as: where S = 2.With λ = 0.50: agentsWith λ = 0.65: agents

With λ = 0.50: agents

With λ = 0.65: agents

In other words, increasing λ decreases the expected number of parallel agents necessary to do one serial agent's work. That, on its own, makes sense. The better the parallel agents work together, the fewer you need for equivalent performance.

The fraction of coding tasks AI can do (𝑓%) is modeled by a standard economics formula "CES"—Constant Elasticity of Substitution[20]—with fixed inputs meaning that coding tasks can't be trivially substituted for each other.[21] As in, automating one type of coding task doesn't mean you can automate the rest (true!), and so an overall coding project is still heavily slowed down by its slowest, unautomated parts. In that case, the main benefit of automation is freeing up humans to spend more time on the fraction of work still not automated (100% - 𝑓%), or simply (1 - 𝑓). The logic goes as follows:The inputs the AI Futures Model uses for their CES end up saying roughly that the increase in parallel labor caused by automation is .But N comes from Step 1 above, where S = 2 is fixed. Only f is free. So to restate: With λ = 0.50 → N = 4: automated (the default)With λ = 0.65 → N = 2.9: automatedYou can see what happened now: by increasing λ, we've decreased the fraction 𝑓% of coding that is automated as of August 2026! That means increasing λ moves AC (100% automation) away from the current day; it lengthens the time to AC!

The inputs the AI Futures Model uses for their CES end up saying roughly that the increase in parallel labor caused by automation is .

But N comes from Step 1 above, where S = 2 is fixed. Only f is free. So to restate: With λ = 0.50 → N = 4: automated (the default)With λ = 0.65 → N = 2.9: automated

With λ = 0.50 → N = 4: automated (the default)

With λ = 0.65 → N = 2.9: automated

You can see what happened now: by increasing λ, we've decreased the fraction 𝑓% of coding that is automated as of August 2026! That means increasing λ moves AC (100% automation) away from the current day; it lengthens the time to AC!

Now, why the heck is the AI Futures Model operating this way?

Well, basically, it's the result of a simplification. λ is a single, fixed value in the AI Futures model. It can't change over time, and it's used for different purposes. In the Coding Uplift anchor case, it's used to determine how close we are to AC today, and this happens to overwhelm the benefit that increasing λ provides to coding uplift. In the Time Horizon and Revenue anchors, the above backcalculation happens too, but AC is defined differently, so the benefit isn't overwhelmed.

Believe it or not, the full story is even more complicated, but the Serial Coding Uplift is by far the dominant side effect caused by λ reuse. See modeling below (Daniel's presets, λ = 0.65):

The red-orange bars are the backcalculation effects that go in the "wrong" direction, while the blue bars are the expected speedup effects from increasing λ from 0.5 to 0.65. Other effects are trivial. As you can see, for the Coding Uplift anchor, the backcalculation side effects overwhelm the first-order speedup effects, whereas for the Time Horizon and Revenue anchors, they cut into expected speedup but don't overwhelm it.

Now, you might have an intuition here: "Okay, so if we remove the backcalculation effects, we ought to be able to see the 'true' speedup from increasing λ from 0.5 to 0.65, which ought to be a substantial effective compute increase. But looking at the numbers, the 'true' speedup is only a single month? Why is it so small?"Well... primarily, this is because of the Constant Elasticity of Substitution formula I mentioned earlier. Parallel coding labor is held back by whatever part of the labor slow Humans still have to do, but that drag vanishes as those final few tasks are automated:

This means that a.) there's a huge speedup eventually, dwarfing λ effects; b.) that speedup mostly happens at the very end of the timeline due to the CES bottleneck.

Also, under default parameters we're only a year away from AC, it's just really close already.[22]

See one you recognize in there?

If you can instantly code anything you want, how much does that speed up AI research? The default AI Futures Model says: no more than 15x.

Intuition pump: you can only run so many AI research experiments at once. Even if you can instantly implement the architecture for 100 brilliant ideas, your datacenter can only run 10 of them at a time, and it might take weeks to do each batch of 10.

If coding alone can massively speed things up, then you get to ASI sooner. If you're pretty bottlenecked by real-time experiments, then you get to ASI later.

From that graph we can see two effects: a.) increasing the asymptote dramatically shortens takeoff; b.) increasing the asymptote allows a higher λ to dramatically shorten takeoff even further.

With the default 15x asymptote, going from λ = 0.5 to 0.65 shortens takeoff by just 10% (ignoring model side effects). With a nearly-unbounded asymptote, it shortens takeoff by more than 3x as much: 34%.[23]

Now, is this low asymptote a reasonable thing for the AI Futures Model to enforce?

Well, yes! It really does make sense that an AC doesn't make AI research instantaneous. The question is just if 15x is the right value. The AI Futures Model doesn't have super strong justifications for the 15x default value, but you can change the parameter yourself if you don't like it, and within the "reasonable" realm of 5x to 25x the effects aren't massive anyway.

Stepping back a bit, it's important to understand that AI Futures Model considers "Research taste" much more important to takeoff/ASI than parallel coding/swarms. "Research taste" is basically: "given that we can only run so many AI research experiments with our limited compute, the bottleneck is now whether or not AI can pick the best possible experiments that increase capabilities the fastest". There are reasons to think this is improving a lot recently but that's outside the scope of our discussion here, except to note that the Infinite Coding Labor Asymptote is just one of several parameters involved. If you're interested in the core logic of the AI Futures Model, the three core "stages" of its logic are well-summarized starting here.

Anyway, because we're reasonably limiting the benefits of higher λ via the asymptote, side effects dominate timeline effects for takeoff/ASI just as they did for time to AC. Yet again, backcalculation is our enemy:

We've already discussed Serial Coding Uplift backcalculation effects, but we see another one here in takeoff: "Calibrating coding labor benefit of higher λ, before today".

You may recognize that from the list of side effects on time to AC. In that case, it had a small effect, and it decreased timelines. Why is it behaving so differently during the takeoff regime? Well, this side effect hits a parameter that matters a lot more during takeoff than prior to AC.

Let's follow the chain of logic. To start with, λ is also applied to Human labor in the AI Futures Model, not just AI labor. So increasing λ naively would change the model's estimate of past, Human-driven developments. In particular, there's a parameter called "Software Efficiency OOMs/year in 2024"[24] which defaults to 1 OOM/year. Increasing λ would increase that parameter too, but the model doesn't want to arbitrarily change that parameter as a side effect, so it adds a calibration step that rescales Software Efficiency back to 1 in 2024. However it does this by… changing the value of β, and for future AIs as well as past Humans.[25]

What's β? Well, let's quote Toby Ord again:

Researchers studying (RSI) use a parameter called r to represent the strength of the feedback loop where a more intelligent AI is even more capable of improving the intelligence of its successor. In their modelling, when the process explodes, with performance rising towards a vertical asymptote. Researchers define r as equal to , where represents how well research scales with parallel labour (more workers) compared to serial labour (more time), and represents the diminishing returns to more research.

Researchers studying (RSI) use a parameter called r to represent the strength of the feedback loop where a more intelligent AI is even more capable of improving the intelligence of its successor. In their modelling, when the process explodes, with performance rising towards a vertical asymptote. Researchers define r as equal to , where represents how well research scales with parallel labour (more workers) compared to serial labour (more time), and represents the diminishing returns to more research.

In other words, β is a "low-hanging fruit" effect where, as you do more and more research into some area, it gets harder to make progress. And then the related r defines whether or not you get an intelligence explosion. No FOOM if making more progress gets impossibly hard! The key to this effect is that if r > 1 you get increasing returns, a self-reinforcing cycle of capability gains. And since r = λ/β, increasing β (that is, decreasing the returns to more research) decreases r.[26]

For example, increasing λ from 0.50 to 0.65 only increases β by ~3%. But this lengthens takeoff by 7%, or about a month, as we saw in the earlier graph.

Speaking of which, the other effect lengthening timelines was something new, called "Adjusting the Coding Automation Efficiency Improvement Factor (η)". What's that?

η is basically: "how many OOMs more efficiently can you use compute for coding each year".[27] η = 3 by default, but it's calculated using parallel AI labor… and you know what that means. It means we need to use λ to translate it into serial labor! And of course, λ is getting reused again here, and again, the AI Futures Model has a deliberate calibration step meant to mitigate the effects of reuse.

That calibration step is explained in the supplementary materials as being basically because the AI Futures team estimated η as 3 from AI inference speed/cost using the fixed assumption of λ = 0.5. In other words, the default value of η was derived using a fixed λ = 0.5, so it'd be nonsensical to then translate η to serial labor via some other value of λ. The model ought to adjust for this before using η downstream. The model does this via the formula .

This is the only mathematical mistake I'm confident I've found in the AI Futures Model, as opposed to mere tradeoffs/simplifications. That adjustment formula only makes sense if η is a normal number… but it's not, it's "how many OOMs more efficiently can you use compute". So:

In other words, we should be multiplying η by 0.5/λ, not raising it to 0.5/λ.

That said, the effect of that error is pretty small within the range of values we care about, only blowing up with λ < 0.3:

Because the error is small, that means that the adjustment we saw earlier was in fact almost entirely correct! It's properly preventing the model from doublecounting the effect of changing λ.[28]

Let's revisit our earlier breakdown of takeoff effects, this time splitting out the "straightforward coding labor benefit" part that's strictly because of the effect on η, and putting that next to the η adjustment effect: (using unfixed η^(0.5/λ) as before)

As you can see, the two effects (the middle blue bar, followed by the middle red bar) cancel out appropriately! Or, well, nearly. You can see that the lengthening adjustment (red) is slightly less than the straightforward shortening effect (blue). In other words, funnily enough, the mistaken formula mostly incorrectly shifts timelines earlier:

Though again, the effect is minimal—on the order of mere days—in the range of λ we care most about, 0.50 to 0.65.

"Adjusting the Coding Automation Efficiency Improvement Factor (η)" is a totally reasonable timeline-lengthening correction, albeit with a minor bug in its calculation.

"Calibrating coding labor benefit of higher λ, before today" is a weird backcalculation effect that (arguably misleadingly[29]) lengthens timelines.

"Serial Coding Uplift" has a backcalculation effect that (arguably misleadingly[30]) lengthens timelines.

"Infinite Coding Labor Asymptote" is a totally reasonable limiter that prevents λ from shortening timelines as much as it would naively.

λ has only a limited effect on takeoff timelines anyway (when excluding side effects), because takeoff is determined mostly by "research taste", and research taste is less determined by λ than the automation of coding is.

Overall, when calculating takeoff timelines, the lengthening backcalculation side effects overwhelm the limited first-order straightforward shortening you get from increasing λ, such that, on-net, increasing λ in the model lengthens takeoff and the date of ASI.

Now that we've learned why increasing λ incorrectly leads to longer timelines in the default AI Futures Model, how about we modify it so that it doesn't?

Fix the minor η adjustment bug. (~3 lines of Python)

Avoid "Serial Coding Uplift" backcalculation effect by keeping f % properly fixed at its set value (default 60%). (~15 lines of Python)

Avoid "Calibrating coding labor benefit of higher λ, before today" backcalculation effect by keeping β properly fixed at its calculated value (default 0.318). (~3 lines of Python)

Working with Claude, I've forked a version of the AI Futures Model with those changes here.[31][32] What's the result? Drumroll…

A nice set of graphs where, for every preset and every anchor, increasing λ shortens timelines![33] Yay! (wait shorter timelines are bad)

…well, it turns out that increasing λ from 0.50 to 0.65 doesn't really shorten timelines that much on its own. We need to increase our resolution to properly see the effect:

But we shouldn't be disappointed! That's good news. At least for me, anyway, I'd prefer to see somewhat longer timelines…

However, λ isn't the end-all, be-all for AI swarm efficiency. Cue Marvel post-credits scene: beware the γ![34] Basically, we can think of γ as a variable which would describe how quickly the Infinite Coding Labor Asymptote (default 15x) rises over time due to improved technology. The intuition is that the asymptote is partly a mere technological hurdle; better harnesses and AI agent message boards could result in not just better coordination λ, but also help remove barriers to how much AI agents can speed up progress, ex. by improving AI research experiment throughput.

Really grappling with how to think about γ is outside the scope of this post, but just remember how our earlier graph showed how timelines dramatically shorten if you increase the Infinite Coding Labor Asymptote: more so than if you increase λ! That was simpler "one asymptote across all time" modeling, but the principle still holds. If that asymptote is increasing, that would probably matter more than if λ is increasing.

If you're interested in γ, I recommend Philip Trammell's work on Bounded Parallelizability.[35] (or his shorter writeup with Epoch AI) Keep in mind that the AI Futures Model does capture at least some of the underlying intuition with its research taste parameters already.

What does the AI Futures Model say about λ?

It's not the most important parameter in the model on its own. Even after correcting for the backcalculation[36] side effects I think aren't justified, moving λ alone from 0.50 to 0.65 only shortens timelines to the Automated Coder and then to ASI by 2% to 5%. Moving it all the way to 1 shortens timelines by 5% to 14%.

This is mostly because the model reasonably constrains λ's effects—even with very efficient parallel AI agents, if they don't have research taste, they can only speed up AI research so much. And you still run into natural economic bottlenecks, where slow processes and required human involvement limit speedup.

If we relax those constraints in the model—say, by increasing the Infinite Coding Labor Asymptote—then timelines start shortening more noticeably, but the primary shortening effect is from relaxing those restraints, not from varying λ itself.

This investigation has made me less concerned than I previously was about increases to λ caused by training models to work in organized swarms (like the one that solved Navier-Stokes). Even if λ does increase like I expect, it probably can't cause FOOM on its own.

Does this mean the AI Futures Model is meaningfully flawed?

Short answer: no.

Long answer: the AIFM is flawed because all models are flawed. The map is not the territory. Yet the AIFM is remarkably not-flawed considering its complexity. The one certain mathematical bug I found has zero effect if you keep λ at 0.50, and that's true for all the default anchors and presets. There are technically some effects on the Monte Carlo simulations the AI Futures Project uses to inform their projections, but they're quite small.[37]

Also, meaningful bugs are hard to find.[38] I'm relatively confident there's at least one more minor bug involving the "Maximum Serial Coding Labor Multiplier" but I'm not sure of it. Even if I go and vibecode a "fix all mathematical mistakes" version of the AIFM,[39] including that suspected one, I find that across the 9 default settings (the three anchors, the three presets), the total effect of the fixes amounts to timeline shifts smaller than a single day.

If you wish to interrogate the conclusions of the AI Futures Project, I expect that challenging the chosen default parameter values will be much more fruitful. But make sure you go through the Supplementary Materials first to understand how they were chosen! You may find the caveats you want are already there.

And don't forget: we have software superpowers now! If you want to get fancy, you can just fork the AIFM source code and make your own model! Give your favorite AI a copy of the AI Futures website writeup, recent blog post update, and the supplementary materials, and then try talking through your understanding of the world and how it contrasts with that of the AI Futures Project. Once you're sure you have a well-founded disagreement, have AI pull the AIFM source code and make a new version that reflects your views, and then see what your views predict!

It would be great if more people tried to rigorously model the crazy AI future we're looking at.

AI use disclosure: I wrote the text of this post myself. I used Fable 5.1, Opus 5.5, and Astra 6 to help reason through my work, brainstorm ideas, write all the code, and check my conclusions. I used Opus 5.5 to create all the charts in this post; the wording used in the charts is mostly Opus 5.5's but I sometimes edited it for clarity. The choices of what to chart were partly mine and partly by Fable 5.1 and Opus 5.5. Code for charts provided here.

Thanks to Hieronym for feedback of the form "wait where's the conclusions? you're making it hard to skim this thing." I have now added conclusions, my b.

^My commentary: λ does kind of look like it has feet and is stepping! Good mnemonic.

My commentary: λ does kind of look like it has feet and is stepping! Good mnemonic.

^I believe λ can be greater than 1 in certain circumstances (aka: even holding compute equal and ignoring time spent, parallel agents can sometimes accomplish more than a serialized agent could) but this is not important for our discussion here. If you're interested in that, see discussion there. (See Footnote 29 in the AI Futures Supplementary Materials for why the AI Futures Model constrains it to 1 anyway.)

I believe λ can be greater than 1 in certain circumstances (aka: even holding compute equal and ignoring time spent, parallel agents can sometimes accomplish more than a serialized agent could) but this is not important for our discussion here. If you're interested in that, see discussion there. (See Footnote 29 in the AI Futures Supplementary Materials for why the AI Futures Model constrains it to 1 anyway.)

^This number is hard to estimate and definitely varies by task, but Toby Ord backed out numbers of λ = 0.48, 0.57, 0.68 on different benchmarks for GPT-5.6, and using a similar method I back out λ = 0.62, 0.64, and 0.66 from benchmarks on the Opus 5.5 system card's section 8.12, and a more imprecise λ ≈ 0.66-0.78 on the Sonnet 5.5 system card's Fig. 8.12.1.A.It makes sense to me that λ would improve over time, considering newer models are deliberately trained to better coordinate, but it's worth noting this is not a guaranteed effect. There's a plausible countervailing effect where, as AI capabilities increase, a single agent can accomplish more complex tasks on its own, so as time goes on, an increasing range of trivialized tasks see λ decrease as coordination between agents becomes pure overhead.Also, the above estimates are on relatively small AI agent swarms. I expect it's true that λ also varies with swarm size; intuitively, there are diminishing returns to adding more agents, esp. for simpler tasks, for the same reason as described in the previous paragraph.If you are still dissatisfied with this claim, I offer the defense that λ = 0.65 is not essential to the second aim of this post, which is to interrogate how the AI Futures Model works when λ is varied. We must choose some new value in order to consider that.

This number is hard to estimate and definitely varies by task, but Toby Ord backed out numbers of λ = 0.48, 0.57, 0.68 on different benchmarks for GPT-5.6, and using a similar method I back out λ = 0.62, 0.64, and 0.66 from benchmarks on the Opus 5.5 system card's section 8.12, and a more imprecise λ ≈ 0.66-0.78 on the Sonnet 5.5 system card's Fig. 8.12.1.A.

It makes sense to me that λ would improve over time, considering newer models are deliberately trained to better coordinate, but it's worth noting this is not a guaranteed effect. There's a plausible countervailing effect where, as AI capabilities increase, a single agent can accomplish more complex tasks on its own, so as time goes on, an increasing range of trivialized tasks see λ decrease as coordination between agents becomes pure overhead.

Also, the above estimates are on relatively small AI agent swarms. I expect it's true that λ also varies with swarm size; intuitively, there are diminishing returns to adding more agents, esp. for simpler tasks, for the same reason as described in the previous paragraph.

If you are still dissatisfied with this claim, I offer the defense that λ = 0.65 is not essential to the second aim of this post, which is to interrogate how the AI Futures Model works when λ is varied. We must choose some new value in order to consider that.

^FYI if you change λ on the AIFM website, it sometimes also changes the current date from the default ~2026.58 to ~2025.6, a year earlier, for reasons I don't understand, which affects other calculations. This post will work entirely from the default 2026.58 date.

FYI if you change λ on the AIFM website, it sometimes also changes the current date from the default ~2026.58 to ~2025.6, a year earlier, for reasons I don't understand, which affects other calculations. This post will work entirely from the default 2026.58 date.

^The AIFM model actually tracks more key milestones between AC and ASI. There's SAR (Superhuman AI Researcher), then TED-AI (Top-Expert-Dominating AI), and then SIAR (Superintelligent AI Researcher), before finally reaching ASI. I'm leaving these out for simplicity. The main website focuses on just AC and ASI dates as well.

The AIFM model actually tracks more key milestones between AC and ASI. There's SAR (Superhuman AI Researcher), then TED-AI (Top-Expert-Dominating AI), and then SIAR (Superintelligent AI Researcher), before finally reaching ASI. I'm leaving these out for simplicity. The main website focuses on just AC and ASI dates as well.

^...as of Aug. 2026 anyway. Previously Time Horizon was the default for reasons described in this writeup, but that was changed for reasons described in this blog post.

...as of Aug. 2026 anyway. Previously Time Horizon was the default for reasons described in this writeup, but that was changed for reasons described in this blog post.

^Under "Advanced Parameters" → "Automated Coder Anchors" → "AC Anchor Mode: Time horizon" → "AC Time Horizon Requirement".

Under "Advanced Parameters" → "Automated Coder Anchors" → "AC Anchor Mode: Time horizon" → "AC Time Horizon Requirement".

^Previously Daniel used 3 years (still referenced in the AIFM writeup), but his latest preset is just 1 year.

Previously Daniel used 3 years (still referenced in the AIFM writeup), but his latest preset is just 1 year.

^Brendan doesn't weight the Time Horizon anchor at all in his predictions, so he just copied Eli's parameters here.

Brendan doesn't weight the Time Horizon anchor at all in his predictions, so he just copied Eli's parameters here.

^Under "Advanced Parameters" → "Automated Coder Anchors" → "AC Anchor Mode: Revenue" → "Annualized revenue corresponding to Automated Coder (AC)".

Under "Advanced Parameters" → "Automated Coder Anchors" → "AC Anchor Mode: Revenue" → "Annualized revenue corresponding to Automated Coder (AC)".

^Should the AI Futures Model default to the Coding Uplift anchor? Well, you can read the AI Futures team's reasoning here, but IMO, yes! Coding Uplift much closer to the real thing we want to measure/predict here! The other two anchors are something more like sanity-check proxies in the current moment; Time Horizon is a decent proxy, but unfortunately it's practically unmeasurable as of H2 2026 for cost/time reasons, so not great for predictions anymore. Revenue isn't bad—famously, Microsoft and OpenAI defined AGI as "makes $100B in profits" for lack of clearer options—but you could imagine that ex. coding remains not fully automated while medical breakthroughs bring in massive revenue.Of course, for actually making predictions in ex. AI 2040, what the AI Futures Team does nowadays is assign weighting to each anchor and let them influence their overall predictions in that more balanced way. Those weightings currently are:Daniel: time horizon 25%, coding uplift 50%, revenue 25%Eli: time horizon 20%, coding uplift 60%, revenue 20%Brendan: time horizon 0%, coding uplift 65%, revenue 35%

Should the AI Futures Model default to the Coding Uplift anchor? Well, you can read the AI Futures team's reasoning here, but IMO, yes! Coding Uplift much closer to the real thing we want to measure/predict here! The other two anchors are something more like sanity-check proxies in the current moment; Time Horizon is a decent proxy, but unfortunately it's practically unmeasurable as of H2 2026 for cost/time reasons, so not great for predictions anymore. Revenue isn't bad—famously, Microsoft and OpenAI defined AGI as "makes $100B in profits" for lack of clearer options—but you could imagine that ex. coding remains not fully automated while medical breakthroughs bring in massive revenue.

Of course, for actually making predictions in ex. AI 2040, what the AI Futures Team does nowadays is assign weighting to each anchor and let them influence their overall predictions in that more balanced way. Those weightings currently are:

^You may notice that I'm excluding values of λ < 0.3 here. Once you reach around λ = 0.2, you start seeing the expected "lower λ means longer timelines" effects, but largely for side-effect reasons, and once you reach λ = 0.06, you start getting errors because the Coding Uplift calibration starts failing. We'll ignore that can of worms on the basis that λ is almost certainly > 0.3.

You may notice that I'm excluding values of λ < 0.3 here. Once you reach around λ = 0.2, you start seeing the expected "lower λ means longer timelines" effects, but largely for side-effect reasons, and once you reach λ = 0.06, you start getting errors because the Coding Uplift calibration starts failing. We'll ignore that can of worms on the basis that λ is almost certainly > 0.3.

^Strictly speaking, on Daniel's presets under the Time Horizon and Revenue anchors, there are ranges of λ where it moves timelines a few days earlier, though over the full range of λ, increasing λ moves timelines later.

Strictly speaking, on Daniel's presets under the Time Horizon and Revenue anchors, there are ranges of λ where it moves timelines a few days earlier, though over the full range of λ, increasing λ moves timelines later.

^I did make one simplification here. When making forecasts from the AI Futures Model, the AI Futures Project ran a Monte Carlo sampling over each forecaster's distributions on the model's parameters. The presets just take the median parameter values from that sampling. I haven't rerun their Monte Carlo sampling as a separate set of graphs, as the presets built from that accurately demonstrate λ effects on their own.

I did make one simplification here. When making forecasts from the AI Futures Model, the AI Futures Project ran a Monte Carlo sampling over each forecaster's distributions on the model's parameters. The presets just take the median parameter values from that sampling. I haven't rerun their Monte Carlo sampling as a separate set of graphs, as the presets built from that accurately demonstrate λ effects on their own.

^Under "Advanced Parameters" → "Automated Coder Anchors". See also Supplementary Materials under "Present day serial coding labor uplift" here.

Under "Advanced Parameters" → "Automated Coder Anchors". See also Supplementary Materials under "Present day serial coding labor uplift" here.

^Side note, per Anthropic's August 2026 Risk Report section 3.4.2, an internal survey run during the time of Mythos Preview estimated uplift then at 4x. However they note that this is probably an overestimate and they distrust the figure so much they stopped running the survey.

Side note, per Anthropic's August 2026 Risk Report section 3.4.2, an internal survey run during the time of Mythos Preview estimated uplift then at 4x. However they note that this is probably an overestimate and they distrust the figure so much they stopped running the survey.

^Under "Advanced Parameters" → "Experiment Throughput Production". See also here.

Under "Advanced Parameters" → "Experiment Throughput Production". See also here.

^The AI Futures team gives more detailed estimates of that value here.

The AI Futures team gives more detailed estimates of that value here.

^More standard term would be "calibrate". To be clear, it is necessary and normal to calibrate many unmeasured parameters in models this complex. It's well known that this creates side effects; they're often a necessary evil.

More standard term would be "calibrate". To be clear, it is necessary and normal to calibrate many unmeasured parameters in models this complex. It's well known that this creates side effects; they're often a necessary evil.

^This is an important result in economic theory. You may be familiar with one of its famous relatives: Baumol's Cost Disease. If some sectors of the economy have productivity massively increase, and others don't, the latter ends up absorbing an increasing share of human labor (and thus spending). See also Amdahl's Law for a similar effect in parallel computing.

This is an important result in economic theory. You may be familiar with one of its famous relatives: Baumol's Cost Disease. If some sectors of the economy have productivity massively increase, and others don't, the latter ends up absorbing an increasing share of human labor (and thus spending). See also Amdahl's Law for a similar effect in parallel computing.

^In other words, it's taken me >5% of the remaining time to AC to draft this LW post as a side project...

In other words, it's taken me >5% of the remaining time to AC to draft this LW post as a side project...

^Slight spoilers for "Adjusting the Coding Automation Efficiency Improvement Factor (η)" but we shouldn't ignore all side effects. We're about to cancel out some of this timeline speedup. The adjusted speedup for λ = 0.65 is just 2.7% at 15x, and 10.2% unbounded. For λ = 1, 6.8% at 15x and 29% unbounded. That does still mean that unbounding the asymptote results in a 4x larger effect from increasing λ!(Also slighter spoilers for Footnote 28, but there's also an argument we shouldn't cancel out as much as we will; the "true" adjusted speedup perhaps falls somewhere in between the given numbers.)

Slight spoilers for "Adjusting the Coding Automation Efficiency Improvement Factor (η)" but we shouldn't ignore all side effects. We're about to cancel out some of this timeline speedup. The adjusted speedup for λ = 0.65 is just 2.7% at 15x, and 10.2% unbounded. For λ = 1, 6.8% at 15x and 29% unbounded. That does still mean that unbounding the asymptote results in a 4x larger effect from increasing λ!

(Also slighter spoilers for Footnote 28, but there's also an argument we shouldn't cancel out as much as we will; the "true" adjusted speedup perhaps falls somewhere in between the given numbers.)

^Under "Advanced Parameters" → "Software Efficiency and intelligence explosions" → "Software Efficiency OOMs/year in 2024".

Under "Advanced Parameters" → "Software Efficiency and intelligence explosions" → "Software Efficiency OOMs/year in 2024".

^To break down the chain:Serial Coding Labor, pre-AI, is defined as parallel Human labor raised to the power of λ:L's growth rate can be found by differentiating with respect to time. That comes out to L′/L = λ · H′/H, or for simplicity, g_L = λ · g_H, where "g_" means "growth rate of". This equation shows that the growth of serial coding labor is λ multiplied by the growth of parallel human labor. Therefore ex. going from λ = 0.50 to λ = 1 means doubling the growth rate, because λ doubled.Available "Research effort" is then modeled via CES as growing as a result of a weighted mix of g_L and compute growth."Research stock", aka cumulative research effort thus far, then depends on the growth of research effort.Software efficiency's growth rate is then modeled as r (= 1/β) times the growth of research stock.Because software efficiency growth rate is fixed at 1 OOM/year at 2024, and everything else we just discussed is fixed by other parameters or in the code except for λ and r, if we increase λ, then we have to decrease r to compensate.Specifically, r = ln 10 × Ṡ₂₀₂₄ / g_RS₂₀₂₄, where Ṡ₂₀₂₄ is 1 OOM/year and g_RS₂₀₂₄ is the growth rate of Research Stock in 2024, which is a mix of the growth of compute and g_L = λ · g_H from earlier. Basically, λ is in the denominator in this equation, so a higher λ means a lower r.The normal equation r = λ/β is split inside the AIFM. λ is applied earlier, so when r is calculated, it's by just r = 1/β. In other words, a higher λ means a lower r means a higher β. So increasing parallel labor efficiency λ has a backcalculation effect where it also diminishes returns to further research β.

L's growth rate can be found by differentiating with respect to time. That comes out to L′/L = λ · H′/H, or for simplicity, g_L = λ · g_H, where "g_" means "growth rate of". This equation shows that the growth of serial coding labor is λ multiplied by the growth of parallel human labor. Therefore ex. going from λ = 0.50 to λ = 1 means doubling the growth rate, because λ doubled.

Available "Research effort" is then modeled via CES as growing as a result of a weighted mix of g_L and compute growth.

"Research stock", aka cumulative research effort thus far, then depends on the growth of research effort.

Software efficiency's growth rate is then modeled as r (= 1/β) times the growth of research stock.

Because software efficiency growth rate is fixed at 1 OOM/year at 2024, and everything else we just discussed is fixed by other parameters or in the code except for λ and r, if we increase λ, then we have to decrease r to compensate.

Specifically, r = ln 10 × Ṡ₂₀₂₄ / g_RS₂₀₂₄, where Ṡ₂₀₂₄ is 1 OOM/year and g_RS₂₀₂₄ is the growth rate of Research Stock in 2024, which is a mix of the growth of compute and g_L = λ · g_H from earlier. Basically, λ is in the denominator in this equation, so a higher λ means a lower r.

The normal equation r = λ/β is split inside the AIFM. λ is applied earlier, so when r is calculated, it's by just r = 1/β. In other words, a higher λ means a lower r means a higher β. So increasing parallel labor efficiency λ has a backcalculation effect where it also diminishes returns to further research β.

^Though that said, the backcalculation effect that results in decreased r doesn't overwhelm the increase to r that increasing λ brings in the 0.50 to 0.65 case. It just, arguably unreasonably, eats into it.

Though that said, the backcalculation effect that results in decreased r doesn't overwhelm the increase to r that increasing λ brings in the 0.50 to 0.65 case. It just, arguably unreasonably, eats into it.

^Technically, for each "progress-year", aka per year of 2025-like growth in effective compute.

Technically, for each "progress-year", aka per year of 2025-like growth in effective compute.

^Nuance: As mentioned in the Supplementary Materials, this is a correct adjustment to the extent that η is derived from estimates of serial agents. But, quoting: "some of our data measures closer to the equivalent of having more copies". To the extent the measurements were of parallel agents, we would want to adjust η less, and thus have λ shorten timelines more.

Nuance: As mentioned in the Supplementary Materials, this is a correct adjustment to the extent that η is derived from estimates of serial agents. But, quoting: "some of our data measures closer to the equivalent of having more copies". To the extent the measurements were of parallel agents, we would want to adjust η less, and thus have λ shorten timelines more.

^You could fairly claim this isn't misleading or wrong to do! It's mostly a question of whether λ was 0.65 all along or whether that only happened recently. My take is that the previous default reading of 0.50 is legitimate, but now λ has increased, so we should model increased λ going forward without letting that change our understanding of the past.

You could fairly claim this isn't misleading or wrong to do! It's mostly a question of whether λ was 0.65 all along or whether that only happened recently. My take is that the previous default reading of 0.50 is legitimate, but now λ has increased, so we should model increased λ going forward without letting that change our understanding of the past.

^Again you could fairly claim otherwise, but I'm relatively confident saying I'd rather keep f % at 60%.

Again you could fairly claim otherwise, but I'm relatively confident saying I'd rather keep f % at 60%.

^Comes with a cute interactive page Claude made for exploring the difference between this fork and the main AI Futures Model.

Comes with a cute interactive page Claude made for exploring the difference between this fork and the main AI Futures Model.

^I've also created another variant on top of this one (interactive page) which allows λ to rise over time according to a new parameter. I think this is probably a better way to model λ… except for the fact that we lack good measurements of how λ has changed over time. Given reasonable growth rates, this does not change timelines a huge amount anyway vs. just changing forward-looking λ.

I've also created another variant on top of this one (interactive page) which allows λ to rise over time according to a new parameter. I think this is probably a better way to model λ… except for the fact that we lack good measurements of how λ has changed over time. Given reasonable growth rates, this does not change timelines a huge amount anyway vs. just changing forward-looking λ.

^Strictly speaking, while AC and ASI both always move earlier, under Eli's presets with Time Horizon and Revenue anchors, takeoff (time from AC to ASI) gets longer by a fraction of a month because AC moves earlier more than ASI moves earlier.

Strictly speaking, while AC and ASI both always move earlier, under Eli's presets with Time Horizon and Revenue anchors, takeoff (time from AC to ASI) gets longer by a fraction of a month because AC moves earlier more than ASI moves earlier.

^Confusingly, this is a different γ than Toby Ord talks about here. Ord's γ is how much longer AI time-horizons get in relation to increasing the number of tokens used....also, it's somewhat similar but different to how the AIFM models things. Arguably their modeling of research taste is similar, though I think a meaningful distinction can be made.Also it's kind of funny that this parameter happens to be gamma (γ), which is kind of like an evil upside-down lambda λ. A worthy villain!

Confusingly, this is a different γ than Toby Ord talks about here. Ord's γ is how much longer AI time-horizons get in relation to increasing the number of tokens used.

...also, it's somewhat similar but different to how the AIFM models things. Arguably their modeling of research taste is similar, though I think a meaningful distinction can be made.

Also it's kind of funny that this parameter happens to be gamma (γ), which is kind of like an evil upside-down lambda λ. A worthy villain!

^Interestingly, Trammell posits that γ ≥ β historically, as that's necessary for steady exponential technological growth. What exactly γ is empirically, either historically or for AI in the coming years, is an important and under-researched question.

Interestingly, Trammell posits that γ ≥ β historically, as that's necessary for steady exponential technological growth. What exactly γ is empirically, either historically or for AI in the coming years, is an important and under-researched question.

^Alt. "calibration".

Alt. "calibration".

^The Monte Carlo simulations sample many parameters across the likeliest distributions of parameter values according to Daniel/Eli/Brendan. λ does get sampled across almost all of 0 to 1, but sampling is concentrated near 0.5 and as it happens the bug causes errors that partly cancel each other out, such that the median date for a given seeded simulation only shifts by days (rarely, weeks). Just varying the seed alone, and thus changing the sampling, typically shifts dates by weeks, or even months for Eli's longer ASI timeline scenarios.

The Monte Carlo simulations sample many parameters across the likeliest distributions of parameter values according to Daniel/Eli/Brendan. λ does get sampled across almost all of 0 to 1, but sampling is concentrated near 0.5 and as it happens the bug causes errors that partly cancel each other out, such that the median date for a given seeded simulation only shifts by days (rarely, weeks). Just varying the seed alone, and thus changing the sampling, typically shifts dates by weeks, or even months for Eli's longer ASI timeline scenarios.

^However, non-meaningful unintuitive behavior around wacky combinations of parameters is easier to find. This is not that worrying—remember the number of possible parameter combinations is insane. For a cute example, with just three parameter changes on Eli's preset I can move the Automated Coder to 2022, four years into the past! (The model is tricked into concluding AI was speeding up AI research 25x in 2017, before GPT-1.) This is something more like a garbage in, garbage out class of behavior.

However, non-meaningful unintuitive behavior around wacky combinations of parameters is easier to find. This is not that worrying—remember the number of possible parameter combinations is insane. For a cute example, with just three parameter changes on Eli's preset I can move the Automated Coder to 2022, four years into the past! (The model is tricked into concluding AI was speeding up AI research 25x in 2017, before GPT-1.) This is something more like a garbage in, garbage out class of behavior.

^Also includes an explanation of the fixes, with interactive elements, by Claude.

Also includes an explanation of the fixes, with interactive elements, by Claude.