Interactive explainer · Draft, 3 November 2026

RSI feedback-loop explorer

An interactive guide to Cunningham, Althoff, Halperin, Jabarian, Koh, Ramani, Trammell, Whitfill and Wu (2026), The Economics of Recursive Self-Improvement (arXiv:2609.15802v1), with The Unjournal’s working evaluation.

What this page is. An adaptation of the paper’s models and calibration, made by The Unjournal to help readers and evaluators see which assumptions drive the headline result. It is not the paper, and the authors have not reviewed or endorsed it. Read the original for the authors’ own presentation.

Credit and licence. The paper is © its authors and released under CC BY 4.0. We paraphrase its definitions and models, redraw its diagrams, and re-implement its back-of-the-envelope calibration as a calculator. Changes from the original are listed in Provenance.

How it was made. Requested by David Reinstein; drafted by Claude (an Anthropic model). Not yet checked by a person. Claude is made by Anthropic, and the paper’s calibration uses Anthropic-reported figures; see Provenance.

In brief

The question. AI now helps build better AI. Does that feedback loop make AI progress speed up on its own, without ever more human researchers or compute?
The paper’s answer, in theory. Not automatically. Acceleration happens only if the loop is strong enough: roughly, if the elasticities around the loop, multiplied together, exceed one. Full automation of AI research is neither necessary nor sufficient.
The paper’s answer, in data. A rough calibration says the loop needs about a 15% gain in research effort per point on the Epoch Capabilities Index. A rough estimate from reported engineer uplift gives about 9%. So: probably not self-sustaining yet, but the authors think the return is rising.
What this page adds. You can change each input in the calculator. Several values the paper itself reports, such as faster estimates of algorithmic progress, are enough to flip the verdict. The paper calls the calibration tentative; the calculator shows how tentative.
Our view. The framework is a real contribution; the calibration is too weakly measured to say how far we are from the threshold. See our working evaluation.

Key terms

The paper separates ideas that are often run together under “recursive self-improvement”. Paraphrased from its Table 1:

Term	Meaning
Feedback loop	Today’s outputs become tomorrow’s inputs. Most technologies have some; AI has had them for a long time.
R&D automatability	AI can make improvements at least as good as human researchers’, at equal cost. Being automatable does not mean labs actually automate.
Self-sustaining acceleration	AI progress speeds up with no growth in outside inputs (human researchers, training compute, and so on). This is the paper’s main object.
Intelligence explosion	Capabilities reach infinity in finite time. A much stronger condition; other writers use the phrase more loosely.
Elasticity	The percentage change in an output from a 1% change in one input, other inputs held fixed. An elasticity of 0.5 means 1% more input gives 0.5% more output.

Why elasticities, and why multiply them?

Each arrow in the paper’s diagrams is a production relationship, and its strength is an elasticity. Going around a loop, the percentage changes compound: if 1% more algorithmic efficiency gives 6.5% more capability, and 1% more capability gives 0.1% more research effort, then the loop returns 0.65% more effort for the 1% you started with. The strength of a loop is the product of the elasticities along it; when there are several loops, their strengths add. If the total exceeds one, each round of improvement makes the next round faster.

These are local elasticities, measured at today’s levels. They can change as the system grows, which is why the paper talks about possible “growth spurts” rather than permanent acceleration.

The models, step by step

The paper builds a sequence of richer models. Pick one to see its diagram and its condition for self-sustaining acceleration. The orange path is the core feedback loop: better algorithms make more capable AI, which speeds up finding better algorithms.

input tocore loopaccumulates into stockoutput finances inputs

Section 2.5: AI that helps only part of the training stack

The paper also considers AI that speeds up some algorithms (say, inference or kernel optimisation, where results are easy to verify) but not others (say, architectures). Progress on the easy part can produce a burst of acceleration that stalls when the hard part becomes the bottleneck, or when the easy part nears a natural ceiling: a kernel running at 50% efficiency can at most double. The paper suggests tracking which kinds of algorithm get the biggest boost from AI-assisted research.

Calibration calculator

The paper calibrates a simplified version of the bottlenecks model. Human researchers, AI researchers (inference compute) and experimental compute are combined into one research-effort index, R. The condition for self-sustaining acceleration becomes a product of three terms:

return to research × ε_R,C (research effort’s response to capability) × ε_C,A (capability’s response to algorithmic efficiency) > 1

The paper has estimates for the first and third terms and solves for the value of the middle term at which the product equals one. It then compares that threshold with a rough estimate of the middle term from reported productivity uplift. The calculator below does the same arithmetic, with the paper’s values as defaults.

1. Return to research paper: 1.0

On a balanced growth path this equals the growth rate of algorithmic efficiency divided by the growth rate of research effort, both in logs.

Algorithmic efficiency growth, per year

All five rates are cited in the paper’s own data table (Section 3.1). The calibration uses 3×, a pretraining estimate.

Research effort growth, per year

The paper assumes 3×, matching growth in lab staff and chips. It notes that inference compute for internal research grew sharply in 2026, so current research-effort growth is likely higher. Higher effort growth lowers the return to research.

2. Capability response to algorithms, ε_C,A paper: 6.5

ECI points per unit of log effective compute

From a regression of the Epoch Capabilities Index on log training compute, assuming algorithms and compute are interchangeable (“effective compute”). The paper flags that algorithmic progress may be scale-biased, which would break that assumption.

3. Research effort’s response to capability, ε_R,C paper: ≈ 9%

The paper has “almost no evidence” here. Its rough estimate spreads a self-reported productivity uplift over the capability gain since Claude Code launched.

Reported productivity uplift

Capability gain over that period, ECI points

Claude 3.7 Sonnet (February 2025) to Claude Opus 4.8: 16 points, as printed in the paper. The paper assumes the uplift was about zero at the start.

Share of research effort the uplift applies to

Our addition, not in the paper’s calculation. The paper notes that research output rises less than human task uplift, because labour is only part of research inputs. At 100% (the default, matching the paper) the full uplift counts.

Loop gain (self-sustaining if above 1)

012+

Return to research ε_C,A Threshold for ε_R,C Implied ε_R,C from uplift

Sensitivity map

Loop gain across algorithmic progress rates (across) and capability responses (down), holding research-effort growth and the uplift estimate at your settings. Blue cells are below 1, orange above. The outlined cell is your current scenario.

Read with care. This is the paper’s back-of-the-envelope calculation, made adjustable. It does not fix its limits: the uplift figure is a self-reported survey, not a causal elasticity; spreading it over 16 ECI points gives an average past response, not today’s marginal response; and the inputs come from different periods and measures. Changing a slider shows sensitivity to that input, not what the right value is.

The arithmetic

Return to research = ln(g_A) / ln(g_R). With 3× and 3× this is 1.

Threshold for ε_R,C = 1 / (return to research × ε_C,A). With the paper’s values: 1 / (1 × 6.5) ≈ 0.154, the “15%”.

Implied ε_R,C = share × ln(uplift) / ECI gain. With the paper’s values: ln(4) / 16 ≈ 0.087, which the paper reports as about 9%. Because capability is defined as exp(ECI), this is the change in log research effort per ECI point.

Loop gain = return to research × implied ε_R,C × ε_C,A. With the paper’s values: 1 × 0.087 × 6.5 ≈ 0.56.

The paper notes that the product ε_R,C × ε_C,A does not depend on how capability is normalised, even though each factor does.

What needs measuring

A distinctive part of the paper is a wish list of data AI companies could measure and plausibly share. It names three biggest unknowns: how fast algorithmic efficiency is growing inside labs; how lab R&D spending splits across researchers, data, experimental compute and inference compute; and direct measures of how much models contribute to research, such as the share of technical advances made by AI. A summary of its tables:

Quantity	What exists	What the paper asks for
Algorithmic efficiency growth	About 3× a year for pretraining; 3.5× to 10× a year for the whole stack; faster at frontier scale than small scale.	Training compute for models released since 2024.
Researchers: spend share and growth	Lab staff growing about 2–3× a year; roughly a third of training cost goes to salaries.	Staff counts by seniority, and researchers separated from engineers.
Experimental compute	Most R&D compute goes to experiments rather than final training runs (around 90% at one lab in 2024).	Experimental compute spending by domain over time.
Inference compute for research	No data.	Inference compute spending by domain over time.
Total R&D spending	Partial estimates from public filings.	Annual R&D spending with a lab-built price deflator.
Substitutability of people and compute	One attempt; inconclusive.	Randomised allocation of staff and compute to teams, or cheaper manager surveys on doubling each.
AI’s effect on researcher productivity	Self-reported uplift of 1.4–2× (METR survey) and about 4× (one lab’s system card); code merged per engineer up about 8×.	A randomised trial of the productivity gain from more capable models.
Autonomous AI research	Models beat time-limited humans on some optimisation tasks but do poorly on complex debugging.	Performance on real model-training problems; returns to AI, human and hybrid research labour.
Capability response to compute	About 6.5 ECI-based; looks close to log-linear.	Efficiency estimates at several scales, to separate algorithms from compute.
AI’s effect on output and lab budgets	Small measured effect on GDP so far; lab revenues growing about 3× a year, but spending is funded mainly by investors.	Task-level adoption linked to output; how lab financing responds to capability gains.

The paper’s evidence for and against acceleration

For

AI already contributes to AI research: self-reported uplift of about 4× at one lab (which the authors think is overstated), models beating human researchers on some research decisions more often than a year earlier, and a reported hundredfold rise in one lab’s research compute share for internal coding inference.
Forecasts: in 2025, experts and superforecasters gave 8–20% to a tripling of effective-compute growth by 2029; a lab co-founder gave 60% to AI that could build its own successor by end-2028.

Against

Compute may bind: algorithmic gains may need more training compute, more AI labour may need more experiments, and the economy may not grow fast enough to fund continued scaling.
AI’s contribution to algorithm optimisation may hit diminishing returns quickly.
Capabilities may depend on data, which is harder to scale.
Political and social barriers, such as cancelled data-centre projects and shifting government stances.

The authors also expect acceleration in narrow, easy-to-verify capabilities (coding, mathematics, optimisation) before broad ones. If it comes, they highlight faster transitions with higher adjustment costs, institutions lagging behind, uneven progress across fields, bigger power gaps between firms and states, and less time to put safeguards in place.

Our working evaluation

Summarised from The Unjournal’s AI-assisted working evaluation (4 October 2026, evidence update 12 October), which assesses this paper alongside Chan et al., What If Automating AI R&D Triggers an Intelligence Explosion? It has not been adopted as a human evaluation or a team decision.

Strong: automating AI research does not by itself imply self-sustaining acceleration. This corrects a common shortcut in public discussion.
Strong, within limits: representing loop strength as products and sums of elasticities. They are local, so they can shift sharply with scale, task mix and complementary inputs.
Useful but imprecise: the 15% threshold. It moves with the capability measure, the return to research, bottlenecks and lags. The calculator above shows this.
Weakest link: the 9% estimate. Engineer uplift mixes changing models, tools, tasks, inference use and lab processes, and a historical average need not equal today’s marginal response. Treat 9% vs 15% as an order-of-magnitude check, not a safety margin.
Do not conflate: the share of tasks AI does, average researcher uplift, and the elasticity of frontier progress to capability. Only the last enters the condition.
A major strength: the narrow vs broad distinction. For safety decisions, though, weak broad economic effects would offer little reassurance if strategically important capabilities improved fast.

Provisional ratings (Cunningham et al.)

Conceptual contribution	4.5 / 5
Formal and model clarity	4 / 5
Empirical calibration	2.5 / 5
Robustness currently demonstrated	3 / 5
Value of further public evaluation	5 / 5

Robustness checks we think matter most

Reproduce every threshold and check the graph rules against the underlying production functions.
Show the full sensitivity surface for the three core elasticities, not just the 15% point.
Replace point estimates with distributions and propagate them to a distribution over loop gain.
Separate task automation share, researcher uplift and frontier-progress elasticity empirically.
Re-estimate the research response with experiments that randomly vary model or tool access.
Measure lags between AI-assisted research, experiments, training runs and deployed gains.
Stress-test strong complementarity with experimental compute, human oversight and data.
Repeat the calibration with other capability measures, such as METR time horizons.
Check whether gains sit in lower-leverage engineering tasks or in advances that improve frontier models.
Model the step from narrow research capability to broad capability separately.

Questions for the authors

How much does the threshold move under other capability measures and normalisations?
Could you share the full calculation behind the 9%, including which models, tasks and dates enter it?
Which input dominates the uncertainty in the threshold?
How do lags between research, experiments and training change the condition or the timing?
How would strong complementarity between AI research labour and experimental compute or human oversight change it?
What evidence would convince you the loop had crossed the threshold?

A separate, blind AI review with Joe Francis’s isitcredible suite (30 October–2 November 2026) rebuilds the calibration and lists 17 issues; several concern the same inputs the calculator varies. It is AI-generated and not checked by a person.

Read the full working evaluation · Isitcredible AI review · Paper brief and human ratings

Provenance

Source

Tom Cunningham, Lukas Althoff, Basil Halperin, Brian Jabarian, Andrew Koh, Arjun Ramani, Phil Trammell, Parker Whitfill and Cheryl Wu (2026). The Economics of Recursive Self-Improvement. arXiv:2609.15802v1 [econ.GN], 14 September 2026. https://arxiv.org/abs/2609.15802. Licensed CC BY 4.0. The authors list a later version at github.com/elasticity-ai/elasticity; this page follows arXiv v1.

Changes from the original

Definitions, models, data tables and arguments are paraphrased and shortened, not reproduced.
Diagrams are redrawn; the Section 2.5 model is described but not drawn.
The Section 4.1 calibration is re-implemented as an adjustable calculator with a sensitivity map. The presets come from estimates the paper cites. The “share of research effort” slider is our addition.
Commentary in the evaluation section and the cautions are The Unjournal’s, not the authors’.

No endorsement

The authors have not reviewed this page and nothing here implies their endorsement. Errors in the adaptation are ours. If you are an author and would like changes, please write to contact@unjournal.org.

How it was made, and conflicts

David Reinstein asked for this page on 3 November 2026. Claude (Anthropic) drafted the text and code from arXiv v1 and The Unjournal’s working evaluation. No person has yet checked it against the paper. Claude is made by Anthropic; the paper’s calibration relies on an Anthropic system-card survey of its engineers and on capability scores for Anthropic models. That is a potential conflict, not evidence of bias, and it is a reason to check the summaries against the original.

Comments

Hypothes.is annotation is enabled on this page; public annotations may be quoted or summarised on other Unjournal pages.