Looped Transformers Explained: How AI Thinks Longer Without Getting Bigger

A looped transformer runs the same block of layers several times before it answers, so a model computes deeper without storing more weights. In October 2026 NVIDIA released a four-billion-parameter model with a setting most models lack: how many times to run its middle layers. With two or more loops, its authors report better average results than selected larger models across twelve benchmarks. Nothing was added to the model. It ran the same weights again.

That result is why a ten-year-old research idea has become an engineering decision. It also comes with a bill. Every extra pass costs compute, some passes buy nothing, and a few make the answer worse. This guide shows you the mechanism, lets you run it yourself, and gives you the numbers to judge it.

What is a looped transformer?

A looped transformer is a language model that sends its internal state through one shared block of layers more than once before it predicts the next token. A standard transformer is a fixed stack: 36 layers means 36 steps, each with its own weights, each used once. A looped transformer keeps a smaller set of layers and reuses it. Depth stops being a property of the file on disk and becomes something you choose when you run the model.

You will meet the same idea under other names: recurrent depth, recurrent-depth models, looped language models. They all describe repeated computation through shared layers.

Two words carry the whole explanation:

• Weights are the numbers learned in training. They are the machinery, and they stay fixed while the model answers.
• Activations (the hidden state) are the model’s working state for one request. They change at every layer and, in a looped model, on every pass.

The loop changes the activations. It never touches the weights. Keep that sentence and most of the confusion around this topic disappears.

How does a looped transformer work?

A looped transformer has three parts: input layers that read the tokens, a shared core that runs several times, and output layers that turn the final state into next-token scores. Each pass through the core takes the previous pass’s result as its input. The weights are identical on every pass. Only the state differs. (Geiping and colleagues)

NVIDIA’s Dory makes this concrete. It has 8 input layers, a 20-layer recurrent block and 8 output layers, 36 stored layers in total. Run the block four times and the model executes 96 layers. (Dory model card)

Before you press play, make a prediction. When you add a loop, which number grows: the layers the model stores, or the layers it runs?

Three things in that animation are easy to miss:

1. What travels round the loop is numbers, not words. No sentence is fed back in. The model has not written a draft and reread it. It has refined an internal state it never turned into text.
2. The weights never change. This is extra computation on the current request. It is not learning, and nothing carries over to the next request.
3. The loop is not the whole model. Layers before and after the core do real work. Dory also feeds the original input back into every pass, so the core does not lose sight of the question.

Parameter count vs computational depth

Parameter count tells you how much a model stores. It does not tell you how much it computes. A looped model splits “depth” into two numbers: stored depth, the distinct layers in the file, and executed depth, the layers that run before an answer appears.

The arithmetic is simple. Eight blocks run three times execute 24 blocks while storing 8. That explains the appeal of weight sharing. It does not promise the accuracy, memory or speed of a real 24-block network, because the reused blocks must cope with a different state on every pass.

So read model claims with both numbers in mind. “Four billion parameters” describes the weights. It says nothing about how many operations happen before the answer arrives.

A smaller model file is not the same thing as a cheaper answer.

The weights became cheaper to store. The answer still has to be computed, pass by pass. Whether that trade is worth making is what the rest of this article is about.

What can more loops fix, and what can they not?

Loops add computation, not information. More passes help when the answer can be worked out from what the model already has. They cannot supply a fact that is missing from both the prompt and the weights.

Take two facts. Alice finished before Bob. Bob finished before Cara. Ask who finished first, and the answer is already in the input. It only has to be assembled. Ask for Alice’s finishing time, and no amount of assembling will help. Try both.

This is the most useful test in the whole subject. Before you reach for a bigger model or a higher thinking setting, ask one question: is the model short on computation, or short on evidence? Looping addresses the first. Retrieval and tools address the second.

One caution. A loop gives the model room for more internal steps. It does not prove the model performs the tidy, human-readable steps we would write down. And “scaling through iteration” is a strategy to measure, not a law: computation goes in, quality comes out, and the relationship between them has to be tested on real tasks.

Looped transformers vs chain of thought, agent loops and RSI

Four different things get called “a loop” in AI. A looped transformer repeats layers inside a single forward pass. Chain of thought repeats token generation. An agent loop repeats model calls and tool actions. Recursive self-improvement repeats the improvement of the system itself. They work at different scales, leave different things behind and bill you in different resources.

These loops stack. In one software task, internal computation can help interpret a failing test, written reasoning can organise a plan, and a tool can run the test that settles the question. The mistake is to see one of these loops and assume the others are happening.

Looping belongs to latent reasoning, the broader practice of doing intermediate work in internal representations instead of text. The trade-off is inspection. Written reasoning can be read, although it is not guaranteed to match what the model actually computed. Activations cannot be read at all.

That does not make a hidden state a secret English paragraph, and missing written reasoning is not evidence of deception or consciousness. The remedy is the same in both cases: check the outcome. Run the tests. Recompute the number.

Are looped transformers recursive self-improvement?

No. A looped transformer improves an answer during one computation. Recursive self-improvement improves the system that performs every future computation.

In RSI AI Explained I describe recursive self-improvement as a process in which a system improves itself or builds a better successor, then uses that gain to improve again. Something persists: a better model, method or tool.

A looped transformer keeps nothing. A person can recheck a calculation three times in one meeting. A company can replace the software used for every calculation from now on. Both involve feedback. Only one changes the future. Looped inference could one day be a component of a system that does AI research, but recurrence alone is not RSI.

A ten-year-old idea: from ACT to Dory

Looping is not new. What is new is that it now works in released language models, with measured serving costs.

The early lesson still applies. A loop is easy to draw and hard to train. Hinton’s account of early recurrent networks describes gradients that grew or shrank multiplicatively across steps, which made long computations difficult to learn. (Hinton, Where Do Features Come From?) ACT itself was a mixed result: strong on synthetic tasks, no large gain in its character-level language-modelling experiment. Flexible computation was a useful idea long before it was a dependable one.

These approaches are relatives, not one architecture. Recurrence across a sequence, adaptive internal steps and equilibrium solving follow different execution rules. They share one question: can a reusable learned procedure turn more runtime into a better result?

Does the brain loop too?

Some of its hardest perception appears to. Neuroscience does not validate any LLM architecture, but it does show that feedback helps biological systems with difficult inputs.

• Hidden objects. Tang and colleagues studied recognition of heavily occluded objects, combining human behaviour, neural recordings and models. Delayed responses and sensitivity to visual masking supported a role for recurrent computation in completing partial images. (Tang et al., PNAS 2018)
• Hard images. Kar and colleagues studied images that challenge feedforward models of vision. For those images, the object information behind a correct answer appeared roughly 30 milliseconds later in inferior temporal cortex than for control images. (Kar et al., Nature Neuroscience 2019)
• Speed against accuracy. Hanks and colleagues related macaque decisions to evidence accumulation under time pressure. (Hanks et al., eLife 2014)

That last study marks the limit of the analogy. A deliberating animal often gathers new evidence. A model looping over a fixed prompt receives none. The fair comparison is modest: brains and looped models both spread computation over time, and some problems benefit from processing that continues past the first response. It is a design analogy. It is not evidence that a model experiences anything.

Do looped transformers actually work? The evidence so far

Yes, in specific reported settings, and with measurable costs. Four results from 2025 and 2026 carry most of the weight. They measure different things, so they do not belong on one leaderboard.

Huginn showed the idea scales. Geiping and colleagues trained a recurrent-depth language model from scratch and reported better reasoning-benchmark results as inference computation increased. The often-quoted “50 billion parameters” is a compute comparison, not a claim that Huginn matches every model of that size. (Huginn paper)

Dory turned loop count into a setting. The same released checkpoint can run at different depths. Its paper also reports a mode that keeps only the final loop’s KV cache, the stored attention data that saves a model from recomputing earlier tokens. That holds cache memory at the non-looped footprint while preserving most of the accuracy gain. (Dory paper)

GLiDE put a price on the gain. Fastino looped two bands of middle layers in a 27B decision model, which chooses among supplied options. The held-out improvement was 0.56 points. The price was about 35% more latency. (Fastino research report)

RLT showed the feedback path matters. Repeated feedback can amplify small errors. The Rectified Looped Transformer preprint mixes the current state with a prediction instead of replacing one with the other. It is early, unreplicated work. (RLT preprint)

There is a fifth finding hiding in the footnotes: you cannot loop any layers you like and expect a gain. Fastino reports testing about 110 candidate configurations, several failed designs and no clear benefit below one billion parameters. A shared block has to work on states from the first pass and the fourth, and that behaviour is learned, not free. It also complicates comparisons. A looped model trained with many passes has not spent the same training compute as an ordinary model with the same parameter count.

Do more loops always help?

No. More loops can improve an answer, stop improving it, or make it worse. Nothing in mathematics forces a learned function to move toward a better answer each time it is applied.

Drag the pass counter and watch three possible outcomes at once. Then look at the bar underneath, which moves in one direction only.

This is why stopping is part of the design. A fixed loop count is predictable and easy to compare. An adaptive scheme tries to spend passes where they help, but it needs a stop signal that tracks real improvement, and a confident model is not necessarily a correct one. Also check whether stopping early saves work in the serving system. An exit rule on paper and a measured drop in latency are different kinds of evidence.

Training matters here too. A model trained at one loop count and served at another may hold up or may drift, because the internal states it meets are no longer the ones it learned on. Treat loop count as a tested configuration, not a volume knob.

Do looped transformers save compute, memory or money?

They save stored weights. They do not save computation, because every pass runs the layers again. Memory and money depend on the implementation, so “efficiency” has to be split into separate accounts before the word means anything.

Two lines need a comment. Latency is how long one request takes. Throughput is how much the system handles across many. A loop setting that suits one user can look poor when hundreds of requests compete for the same GPU. And fewer generated tokens, as Dory reports, are one line in the bill, not the total. A model can write less while doing more work per token.

The account that decides the matter is the cost of failure. A fast answer that needs a retry, a human correction or a second tool call can cost more than a slow correct one. My own measure for this is Joules per Verified Task: the energy spent per result that passes verification. It is my evaluation lens, not a published finding about looped models. Parameter counts and token counts are not measurements of energy. Any claim of energy savings needs hardware measurements on a defined workload at a stated quality target.

Is this how “thinking levels” work? Inference-time scaling

Not necessarily. A higher thinking level and a looped transformer are both forms of inference-time scaling, but they can spend the extra computation in different places.

Inference-time scaling means one trained model has several operating points, in the way one engine can run at different loads. Google’s Gemini 4 Hydrogen, released on 12 November 2026, is a current example.

The model name stays the same while the setting changes. That is a three-point difference on a benchmark index, not a percentage increase in intelligence. And it does not show that Hydrogen is a looped transformer. Its model card describes extra token use and possible slowness at higher settings, not shared-layer recurrence. (Google’s announcement, Hydrogen model card)

Extra inference compute can go into generated reasoning tokens, into parallel exploration of candidate ideas, as Google described for Deep Think, or into repeated internal layers. (Google on Deep Think) Looping is one route among several.

Elapsed time is a poor guide to any of them. A slow answer may reflect useful reasoning, a queue, a tool waiting on the network or slower hardware. The budget is something you set. Capability is something you measure.

The future: smaller reasoning models with tools

My hypothesis: the most useful models will be compact reasoners with an adjustable compute budget and reliable tools, not ever-larger stores of memorised facts. This is a view about system design. The papers above do not establish it.

Consider an old Windows XP product key, or the cryptographic hash of a particular software image. Memorising such a string is a poor substitute for fetching it from an authorised record or computing it from the actual file. The valuable skill is knowing which source or operation settles the question, and how to verify that the result belongs to the right object. The same holds for ordinary work. An invoice query needs the current invoice and the contract. An incident needs the real logs.

In that design, three parts do three jobs. Looping supplies more internal steps to interpret a task and relate evidence. A tool supplies a missing fact or runs a check. A verifier decides whether the answer meets a concrete requirement.

There is a serious objection, and it is correct: knowledge is what tells a model what to look up. A model that knows almost nothing writes poor searches, misses contradictions and accepts confident nonsense. General concepts, causal understanding and domain knowledge are the machinery for judging evidence. Tools also fail. Sources are wrong or stale, permissions block queries, and a lookup can return the right-looking value for the wrong entity.

So the promising version is selective. Keep enough learned knowledge to understand the world and judge evidence. Use external systems for exact, changing, private or auditable facts. Spend extra inference compute on the reasoning that connects them. None of this shows that compact dense models will beat mixture-of-experts designs, or that fewer parameters always means better economics.

What would persuade me is a smaller system that reliably completes the same real tasks with fewer total resources, while making its evidence easier to inspect.

How to evaluate a looped transformer on real work

Start with the failure, not the architecture. More internal processing is the wrong fix for a missing document, and a calculator beats another unverified reasoning pass on arithmetic. Pick the symptom you actually see.

If looping is a real candidate, test it like any other configuration:

1. Choose a task with a pass/fail criterion. Tests for code. A checked reference for extraction. Downstream cost for routing.
2. Run the same model at every supported loop count. Hold prompts, sampling, tool access and output limits constant.
3. Plot quality against end-to-end latency, then against total cost including retries. Measure peak memory and sustained throughput separately, and look at the slowest requests, not only the median.
4. Read the marginal return. If one to two loops helps and two to four adds little, two is your default.
5. Split results by task type. An average can hide a class of task that gets worse.
6. Compare against the honest alternatives: a larger ordinary model, a longer written reasoning budget, retrieval, a tool call, or a second candidate checked by a verifier.
7. Confirm on fresh examples. Choosing the best of many settings on one benchmark tunes to that benchmark.

This is a procedure I propose. I have not run these experiments on the models discussed here. Looping becomes compelling when its advantage survives that accounting.

Glossary

• Looped transformer: a language model that runs one shared block of layers several times before predicting the next token.
• Recurrent depth: applying a shared block of layers repeatedly, so the model executes more layers than it stores.
• Weights: the numbers learned in training. They stay fixed while the model answers.
• Activations (hidden state): the model’s working state for one request. They change on every pass.
• Latent reasoning: intermediate computation carried out in internal representations instead of written text. Looping is one way to do it.
• Chain of thought: intermediate reasoning written out as generated tokens.
• Inference-time scaling (test-time compute): spending more computation on a request when running a trained model.
• KV cache: stored attention data that saves a model from recomputing earlier tokens.
• Halting: the rule that decides when a model stops looping.

For years the question was how big a model had to be. Looped transformers add a second question: how long should it be allowed to work? The answer is not a law of nature. It is a setting, and settings are things you measure.

If a colleague is choosing between a bigger model, more thinking time and better tools, send them the four kinds of loop. It is the fastest way to stop three different arguments from being treated as one.

Research reviewed: 15 November 2026. Interactive figures are original explanatory illustrations. Measured results are attributed to their authors beside each figure.