# Recurrent Looped Transformer: A New Architecture for Infinite Context Reasoning in Language Models
## Introduction
The dominant decoder-only large language models today follow a straightforward pattern: each token is computed independently based on all previous tokens through self-attention, and when the model moves from processing a user’s prompt to generating a response, the computation resets. A researcher has proposed a radical alternative that challenges this assumption.
The Recurrent Looped Transformer (RLT) introduces a continuous state mechanism that carries the decoder’s final hidden representation and its attention cache seamlessly from prompt tokens into response tokens and across multiple conversation turns. Rather than treating the prompt-response boundary as a hard reset, RLT maintains an unbroken computational thread that grows deeper with every additional token processed.
This technical report lays out a complete design specification for the architecture, detailing how the model would be built, how it would train, and how it would serve in production scenarios. Notably, the document does not report any empirical measurements — no benchmark scores, no efficiency metrics, and no scaling experiments. It is purely a proposal for what could become a new paradigm in transformer-based language modeling.
## How the Architecture Works
### Encoder-Decoder Pairing with Shared Weights
RLT consists of two main components: a causal encoder and a recurrent decoder. The encoder processes the input sequence in parallel, applying a causal mask so that each position can only attend to previous tokens. It produces a set of representations that get projected into key-value memory, which the decoder can reference during generation.
What makes RLT distinctive is how it handles parameter sharing. In the reference configuration, the encoder and decoder each contain 48 layers, and the attention weights and feed-forward network weights between corresponding encoder and decoder layers are tied together. This means each individual token requires 96 logical blocks of computation — 48 from the encoder and 48 from the decoder — though the decoder blocks carry additional work through cross-attention mechanisms.
### The Recurrent Decoder State
The heart of RLT lies in its decoder recurrence. The complete decoder state at any point consists of two components: the final hidden output from the decoder and a sliding-window attention cache that retains keys and values across every decoder layer. When processing a new token, the model merges the encoder’s current representation with the previous decoder output through a gating mechanism. Then each decoder layer performs three operations: self-attention over the recent window of decoder activations, cross-attention to the encoder memory, and a feed-forward transformation.
The sliding window means that only a fixed number of historical entries per layer are kept — the current token plus W minus 1 previous entries — bounding the memory cost for attention cache. The model starts with a learned initial state and an empty cache before the beginning-of-sequence token, and from that point forward, the state flows continuously through every subsequent token.
### The Critical Boundary: No Reset Between Prompt and Response
In conventional transformer-based language models, the transition from prompt processing to response generation typically involves clearing or resetting certain internal states. RLT eliminates this discontinuity entirely. The same transition function applies to every token regardless of whether it falls in the user’s prompt or the model’s generated response. This design choice is formalized in a proposition showing that the conditional distribution over the next token remains unchanged regardless of where the prompt-response boundary is drawn, as long as the history of tokens is identical.
## Three Foundational Design Principles
### Principle 1: Latent Reasoning Through Structural Depth
RLT’s first design principle leverages the fact that the recurrent state path from the start of a sequence traverses multiple decoder blocks for every token processed. After t tokens, the state has passed through t multiplied by the number of decoder layers worth of transformations. In the reference 48-layer configuration, this means the computational path deepens linearly with sequence length while the per-token work remains constant.
The researchers are careful to note that this structural depth does not automatically translate into reasoning capability. Gating mechanisms, contraction operations, and learned projections within the model could potentially suppress the flow of information across these long paths. The report frames this as a hypothesis worth investigating rather than a proven advantage.
### Principle 2: Co-Design Between Model and Hardware
The second principle addresses the practical tension between the recurrent nature of the decoder and the parallel computing hardware on which it would run. Encoder operations and memory projections for known tokens can be parallelized effectively using token-parallel kernels. However, the decoder recurrence is inherently sequential within a single sequence — each token depends on the state produced by the previous one.
The report acknowledges that no exact parallel scan exists for the nonlinear decoder recurrence and that a standard parallel sliding-window attention pass is not equivalent to the proposed recurrent mechanism. Implementation targets include batching across independent sequences, kernel fusion to reduce memory overhead, and checkpointing strategies to manage the computational graph. The researchers explicitly state that no reduced prefill speedup has been claimed or demonstrated.
### Principle 3: Co-Design Between Model and Reinforcement Learning
The third principle makes RLT particularly interesting for RL-based training approaches. Because the model’s state transition function is consistent across pretraining, supervised fine-tuning, sampling, and RL replay, the same state machinery serves all phases. During RL training, the sampler records each action’s behavior log-probability under its actual sampling conditions, including temperature settings and truncation decisions. The trainer then rebuilds the entire encoder memory, recurrent output, and every SWA cache from the sequence beginning before scoring each action.
This ensures that no stale rollout states are ever reused. When model parameters are updated, all cached states become invalid and must be recomputed from scratch under the new parameters. The report formalizes this with a replay contract that maintains the integrity of importance ratios used in policy gradient objectives.
## Training and Serving Considerations
### Training Methodology
Pretraining in RLT uses full-sequence next-token prediction with complete backpropagation through time. During supervised fine-tuning, the loss is masked to only assistant-generated tokens, but crucially, state updates are never masked. This means that gradients from assistant losses flow backward through user tokens and tool-call tokens as well, allowing the model to learn from the full context of each interaction.
The report identifies a subtle pitfall with partial detaching strategies. Because the state-to-state Jacobian includes cross-terms through the decoder’s key-value cache, detaching only the final output state still leaves gradient paths running through the cache. Any truncated backpropagation through time scheme must explicitly name every tensor that gets detached to avoid unintended gradient flow.
### Multi-Turn Serving
For serving scenarios involving multiple conversation turns, RLT requires an exact prefix snapshot that captures the encoder cache and memory, the complete decoder state, position metadata, the sliding window convention, and the model version. Because the state is independent of how the serving system splits the computation, a fixed-weight snapshot can be safely reused across requests.
However, if model weights are updated, all previously cached states become invalid and must be discarded. Similarly, editing or truncating a prefix requires recomputation from an earlier checkpoint, as the recurrent state depends on the complete history of tokens processed so far. The report also notes that external tokens introduced during multi-turn RL training update the state but do not receive importance-ratio factors, since they were not part of the original behavior policy’s sampling distribution.
## Relationship to Prior Work
RLT builds on several established ideas in the literature. The use of encoder-derived memory follows approaches like YOCO and DeepSeek-V4.1-Flash, which cache or project key-value representations from encoder final states for cross-decoder attention. However, RLT differs by dropping prompt-wide decoder skipping and maintaining the memory continuously.
The temporal feedback mechanism connects to the Feedback Transformer and Recurrent Transformer architectures, but RLT uniquely feeds the previous final decoder output into the next decoder’s input rather than using alternative recurrence schemes. The depth-wise reuse concept draws from Universal Transformers and recurrent-depth latent reasoning approaches, while the RL replay argument extends earlier observations about the mismatch between prefill and decode kernel execution patterns.
## Frequently Asked Questions
**What is the key innovation of the Recurrent Looped Transformer?**
The key innovation is eliminating the computation reset that normally occurs at the boundary between a user’s prompt and the model’s response. By carrying the decoder’s final hidden state and its attention cache continuously across this boundary, RLT creates an unbroken computational path that grows deeper with every token processed.
**Does RLT actually demonstrate improved performance?**
No. The technical report is a design specification that defines the architecture, execution schedules, and training contracts. It explicitly states that no measured efficiency, reasoning quality, or scaling results have been produced. The proposal is purely theoretical at this stage.
**How does RLT handle very long conversations?**
RLT uses a sliding window attention mechanism in the decoder, where each layer retains only a fixed number of historical key-value entries (the current token plus W-1 previous ones). This bounds the memory cost for attention caching, though the recurrent state itself grows in structural depth with the length of the conversation.
**Can RLT be parallelized effectively given its recurrent nature?**
The report is honest about this limitation. Decoder transitions are inherently sequential within a single sequence because each token depends on the state of the previous token. Parallelism can be achieved across independent sequences and in the encoder, but the core decoder recurrence resists parallelization. The researchers list batching, kernel fusion, and checkpointing as targets for future implementation work.
**What happens when model weights are updated during RL training?**
All cached states — encoder memory, recurrent outputs, and SWA caches — become invalid and must be rebuilt from scratch under the new parameters. The training loop samples a fresh rollout under the current behavior policy, then the trainer rebuilds everything from the sequence start before computing gradients. Stale states are never reused.
**How does RLT differ from simply using a very deep transformer?**
In a standard deep transformer, each token passes through the full depth independently of other tokens. In RLT, the state path traverses decoder layers sequentially across multiple tokens, creating a path whose length grows with the sequence. This is a fundamentally different computation graph that could, in principle, allow information to propagate across many more computational steps for a single decision.
**Is parameter reuse the same as activation checkpointing?**
No. RLT uses parameter reuse — sharing the same weight matrices between encoder and decoder layers — not activation copying or checkpointing. Each token still executes 96 logical blocks, but the encoder and decoder blocks share weights, reducing the total number of distinct parameters in the model.
## Conclusion
The Recurrent Looped Transformer represents a thought-provoking departure from the standard decoder-only transformer paradigm. By closing the loop between the final decoder state and the next token’s computation — and doing so continuously across prompts, responses, and conversation turns — RLT challenges the assumption that transformer-based language models need discrete boundaries between input processing and output generation.
The three design principles offer a coherent framework for thinking about how architectural choices interact with hardware constraints and training methodologies. The model-RL co-design principle, in particular, opens interesting avenues for combining recurrent state mechanisms with reinforcement learning from human feedback and other alignment techniques.
However, significant questions remain unanswered. The report does not provide evidence that the proposed structural depth translates into meaningful reasoning improvements, nor does it address the practical challenges of training such a model efficiently. The inherently sequential nature of the decoder recurrence may create substantial computational bottlenecks on current parallel hardware.
As a design specification, RLT provides a valuable blueprint for researchers interested in exploring recurrent connections within transformer architectures. Whether the theoretical advantages materialize in practice will depend on future experimental work that this report intentionally leaves for others to undertake.
Thank you for reading
