Skip to main text
← DeepDive Agents & Models · v1
DEEPDIVE / [ARCHITECTURE] · Loop Transformer
v1 · 2026 · SEP 04 · First published
§ 00 · ARCHITECTURE / Looped Depth & Chain-of-Thought Monitoring

Looped Transformer:
Decoupling compute from parameters,
until it hits the chain-of-thought monitoring red line

A standard Transformer gets stronger by stacking layers; a Looped Transformer runs a small set of shared parameters through multiple passes, completely decoupling "how much compute to spend" from "how many parameters to store." This was originally a VRAM-saving engineering trick, proven Turing-complete in 2023, and over the past year has grown from papers into three real products. On September 1, 2026, a report about OpenAI's next-generation model Astra pushed this technology directly onto the most heated question in the AI safety community: when a model's "thinking" increasingly happens inside unreadable loops, can humans still understand what it is thinking?

SWE-BENCH VERIFIED
64.4
LOOPCODER-V2 with 2 loops; only 43.0 without looping
TRAINING DATA EFFICIENCY
5×
OURO 1.4B/2.6B matches Qwen3 trained on ~5× the data
TRAINING COMPUTE SAVINGS (54B, ISO-COMPUTE)
18%
SMELT, without giving the looped architecture any compute advantage
EXPLOITBENCH
100%
GPT-6 ASTRA, first to cross the "CRITICAL" cybersecurity threshold
— TABLE OF CONTENTS —
  1. 01 · Mechanism: From "Stacking Layers" to "Looping"
  2. 02 · The Turing-Completeness Proof: A Hand-Constructed Counterexample
  3. 03 · Foundation Paper: Dynamically Allocating Loop Depth per Token
  4. 04 · 2025–2026 Key Papers Overview
  5. 05 · Real Deployments: Three Named Cases
  6. 06 · The One Plain-Selling Point, and the Old Problems Still Unsolved
  7. 07 · The Astra Controversy: From Anonymous Leak to Official Admission
  8. 08 · Control Group: Why the Mythos "Looped Architecture" Rumor Isn't Credible
  9. 09 · The Real Bet: A Warning One Year Early
  10. 10 · Synthesis

TL;DR · 30-SECOND READ

Looped Transformers decouple "parameter count" and "compute" into two variables you can spend on separately; over the past year they've grown from an academic toy into real products. But they are also an architecture that allows a model's "thinking" to happen entirely inside unreadable hidden states. In September 2026, these two threads collided in GPT-6 Astra.

Counter-consensus insight: In this panic, the specific charge that "OpenAI is using some dangerous architecture" currently has the strongest evidence; but the broader technical judgment that "looping automatically suppresses visible chain-of-thought" does not hold up under calm dissection by independent researchers—what really deserves scrutiny is the scaling effect of compute, not the looping mechanism itself.

§ 01 / MECHANISM

From stacking layers to
looping

A standard Transformer "stacks layers"—it stacks N layers with different parameters; the deeper the model, the more parameters, locking the two together. A Looped Transformer "loops"—it runs a small set of shared parameters through N passes, completely decoupling "how much compute to spend" from "how many parameters to store." To make the model compute deeper, you don't need to store another copy of weights; you just loop a few more times.

This idea didn't come out of nowhere. It traces back to Google's 2019 Universal Transformer (Dehghani et al.)—which replaced fixed depth with looping, allowing the model to adjust computation based on input difficulty—and the ALBERT paper's cross-layer weight sharing (which used shared parameters to slash BERT's storage footprint by an order of magnitude). But at the time, both efforts were more like efficiency-optimization side branches; no one treated them as a mainline architecture worth serious investment.

STANDARD TRANSFORMER

Input → Layer 1 (params θ₁) → Layer 2 (params θ₂) → … → Layer N (params θN) → Output. N layers = N copies of distinct weights; model depth and parameter count grow at a 1:1 ratio.

LOOPED TRANSFORMER

Input → Loop block (same params θ) → Output fed back to input → Pass through loop block again → … Repeat R times → Output. R loops = 1 copy of weights used R times; depth (effective compute) and parameter count are independent.

Parameter count determines how much knowledge the model can memorize; loop count determines how much compute the model is willing to spend on a question—
for the first time, these two things can be paid for separately.

How complex the program is only shows up in how many times it loops; the model's own parameter count doesn't need to increase at all. — Core thesis of "LOOPED TRANSFORMERS AS PROGRAMMABLE COMPUTERS," GIANNOU ET AL., ICML 2023
§ 02 / TURING-COMPLETE

A hand-constructed
counterexample

What really nailed the Looped Transformer was the 2023 foundational paper "Looped Transformers as Programmable Computers" (Giannou et al., ICML 2023). The authors didn't train a model; instead, they hand-constructed a set of weights that lets a 13-layer Transformer with repeated looping simulate a real computer—implementing memory reads/writes, conditional branches, and function calls, proving the mechanism Turing-complete.

The specific approach splits the input sequence into three parts: scratchpad, memory, and instructions. The Transformer's output after one round is fed back entirely as input, serving as the starting point for the next loop—this feedback arrow is the core of the entire mechanism. The key conclusion: how complex a program is only shows up in "how many times it loops"; the model's own parameter count doesn't need to increase at all.

This paper itself isn't a usable product; it's more like a mathematical existence proof—first pinning down "what Looped Transformers can theoretically achieve," giving the engineering papers of the next two years a ceiling to benchmark against.

§ 03 / FOUNDATION PAPER

Simple tokens exit early,
hard tokens loop more

The most important step from "mathematical proof" to "trainable architecture" in these two years was "Mixture-of-Recursions" (KAIST / Mila / Google DeepMind joint team, NeurIPS 2025). It solved a problem that previous Looped Transformers hadn't seriously addressed: early schemes assigned the same loop count to every token, but function words like "the" or "of" and a complex mathematical proof require vastly different amounts of computation.

Mixture-of-Recursions' approach is to assign loop depth individually per token: simple tokens exit the loop early, hard tokens stay in and compute more rounds. The paper's visualization is intuitive—dark cells indicate "this token was computed at this layer," light cells indicate "skipped"; within the same sentence, common function words exit early, while tokens requiring reasoning stay in the loop.

This paper is the foundation for nearly all subsequent 2025–2026 Looped Transformer papers—it transforms "looping" from a coarse-grained switch applied uniformly across the entire sequence into a resource allocation problem that can be finely tuned per token, opening up space for the next step of engineering optimization.

§ 04 / PAPERS OVERVIEW

Standing on the foundation,
a dense burst of five improvements

Standing on the Mixture-of-Recursions foundation, a dense cluster of finer improvement directions emerged from late 2025 into 2026—some solving "can loop count be dynamically adjusted at inference time," some solving "training collapses when loop count gets high," and one extreme case that involves no training at all, purely hand-constructed, to verify the theoretical lower bound of Looped Transformers.

Paper / Project Team · Venue Core Method Key Numbers
LoopFormer ICLR 2026 Borrowing diffusion models' "shortcut consistency" training; loop count becomes an adjustable "budget knob" at inference time Perplexity 10.28 at 24× budget, approaching the 9.49 of a 24-layer fixed-depth baseline
Fully Looped Transformer Hong Kong Baptist University / Jilin University Laying residual connections into every sub-layer, suppressing training collapse caused by "gradient oscillation / residual explosion" Downstream task performance improvement up to 13.2%
LoopCoder-v2 Beihang University / IQuest Research Cross-loop positional offset + shared KV gated sliding-window attention; latency doesn't grow significantly with loop count 2 loops: SWE-bench Verified 64.4 (vs 43.0 without looping); 3+ loops drops to 27.6
Loom Single author · Pure hand-construction, no training A 4.7M-parameter, 8-layer, 22-instruction Looped Transformer "computer" All 50 test C programs pass; can even play Snake in a browser and DOOM
Parallel Loop Transformer ByteDance Cross-Loop Parallelism: loop steps of different tokens are computed in parallel within the same forward pass; KV cache only keeps the first round Preserves deep-loop model accuracy; latency and VRAM overhead nearly match a standard non-looped Transformer

Taken together, these five papers tell a coherent story: LoopFormer solves "can loop count be adjusted like a knob," Fully Looped Transformer solves "will training collapse when loop count gets high," LoopCoder-v2 uses benchmark data to verify a counter-intuitive conclusion—more loops ≠ better; there exists an optimal loop count, past which returns regress—while Loom, a purely hand-constructed extreme case with no training at all, corroborates the §02 Turing-completeness proof from the other direction: even with only 4.7M parameters, as long as the loop count is sufficient, it can still run real C programs. Parallel Loop Transformer handles the last engineering hurdle—the latency and VRAM overhead introduced by looping.

§ 05 / REAL DEPLOYMENTS

Three cases with
verifiable names

This architecture is no longer just a toy in papers. ByteDance Seed team's Ouro model uses 1.4B / 2.6B parameters to match the performance of traditional 4B / 8B-class models. The same team (in collaboration with Tsinghua University) subsequently published a more rigorous paper, "SMELT"— strictly equalizing per-token compute, total parameters, and KV Cache, giving the looped architecture no compute advantage. After scaling to 54B parameters, the looped version still saves 6.8%–18.0% of training compute over the non-looped baseline, with the advantage being more pronounced in code tasks, long texts, and scenarios with more in-context examples. The paper's mechanistic explanation: when the model "goes through again," it reduces attention sedimentation on meaningless tokens and redirects attention back to tokens with actual content. From "building a competitive product" to "producing an un-gamed academic proof," ByteDance Seed's line of work is quite solid.

Nanbeige Lab (affiliated with the publicly listed company BOSS Zhipin / Kanzhun Technology, not a startup) released Nanbeige4.2-3B following the same path—trained from scratch on 28 trillion tokens, looping the same 22-layer stack twice (equivalent to 44 layers but without storing extra parameters). Benchmarks show that two loops offer the best cost-performance ratio, retaining ~75% token efficiency; additional loops yield diminishing returns.

IQuestLab—the AI research division of quantitative fund Jiukun Investment, following the same pattern as DeepSeek's origins in High-Flyer Quant—released IQuest-Coder-V1-40B-Loop also using a looped architecture. These three are the real deployment cases with verifiable names and papers. Other online articles packaging "Looped Transformer" as some mathematical-economics breakthrough, full of metaphors and adjectives but lacking a single specific lab, paper, or dataset, are better treated as background noise than as credible sources.

Model Team Loop Config Comparison Result
Ouro-1.4B / 2.6B ByteDance Seed Shared layer stack looped 4 steps (R4), trained on 7.7T tokens MATH500 82.4 / 90.8, surpassing Qwen3-4B(59.6) / Qwen3-8B(62.3) trained on 36T tokens (~5× data)
Nanbeige4.2-3B Nanbeige Lab (BOSS Zhipin / Kanzhun Technology) 22 layers looped twice, equivalent to 44 layers, trained from scratch on 28T tokens SWE-Bench Verified 63.6, surpassing Qwen3.5-9B(53.1) / Gemma4-12B(44.2) with 3–4× the parameters
IQuest-Coder-V1-40B-Loop Jiukun Investment IQuestLab 80 layers implemented by looping a 40-layer stack twice HumanEval 97.6 (surpassing standard version's 93.9), but SWE-Bench Verified 69.4 is below standard version's 71.2—generation tasks improve, long-horizon agentic tasks regress; officially positioned as an experimental prototype

Sources: Original papers and IQuestLab official release page.

§ 06 / TRADE-OFFS

The one plain selling point,
and the old problems still unsolved

From "stacking layers" to "looping," the Looped Transformer's one plain selling point is decoupling compute from parameter count—for the same parameter budget, you get deeper effective computation; for the same compute budget, you get a smaller storage footprint. In scenarios where VRAM and deployment costs are hard constraints, this is a tangible engineering benefit.

But the three "unsolved" items in the §04 table are also real: there exists an optimal loop count, past which returns regress (LoopCoder-v2's loop-2 optimum); when loop count gets high, training itself can collapse due to gradient oscillation and residual explosion (Fully Looped Transformer had to specifically fix this); and the latency and VRAM overhead introduced by looping require dedicated engineering solutions like Parallel Loop Transformer to counteract. IQuest-Coder-V1-40B-Loop's benchmark results also serve as a reminder: looped architecture is not a universal win—generation tasks (HumanEval) improve, but long-horizon agentic tasks like SWE-Multi and CodeArena regress, and the team itself positions it as an "experimental prototype."

Looped Transformer is currently more like "a tool that works well in specific scenarios," not "the next generation of general architecture"—ByteDance Seed's rigorously equalized SMELT paper proves its real benefits at large scale under compute constraints, but the same engineering community is also密集ly patching its problems, indicating this line of work is still some distance from "working out of the box."

§ 07 / ASTRA CONTROVERSY

From anonymous leak to
official admission

This parameter-saving technique soon also answered a more sensitive question: where does AI actually "think"—in readable chain-of-thought text, or inside unreadable hidden states? On September 1, The Information, citing anonymous sources, reported that OpenAI's next-generation model Astra would use an inference technique called "recurrent depth"—the same query is processed repeatedly inside the model. Critics call this approach "opaque recurrence" because it leaves fewer readable traces than a conventional chain of thought (The Information's original article is behind a paywall and could not be directly verified; this is relayed from safety researchers' public responses).

Redwood Research CEO Buck Shlegeris personally said on X: "I am extremely concerned about the reports of Astra using opaque recurrence... if OpenAI pushes this technology further, they will have the ability to dramatically increase loop intensity, completely destroying the monitorability of chain of thought."

Redwood chief scientist Ryan Greenblatt said: "My biggest worry is that the natural next step of evolution would be to scale up opaque reasoning further, until the model thinks almost entirely in latent space... I hope it's not too late to stop now."

@bshlgrs · @RyanGreenblatt, 2026-09-01

OpenAI's response left room: the report explicitly stated that Astra's use of this technique "appears to be limited," chain-of-thought is expected to remain readable, and the company rebutted the notion that it would "shift to neuralese"; chief scientist Jakub Pachocki wrote on X that "since our first-generation reasoning model, OpenAI has been working to preserve and leverage chain-of-thought monitoring... this is a core objective of our current research plan"—this statement reads more like a reaffirmation of stance than a direct answer to the specific question of "whether Astra actually uses recurrent depth."

Independent researcher Sebastian Raschka wrote a calmer technical dissection the next day, with a rather pointed observation—he noted that "reusing the same layer" itself doesn't automatically suppress visible chain-of-thought; "it just adds some extra computation to the hidden state before generating the next token, which is exactly what standard Transformer layers do." His more cautious interpretation: if a model loops more times, it may indeed need to generate fewer intermediate reasoning tokens, shifting more computation into unreadable hidden activations—but this effect is essentially the same as just making the model bigger, and isn't necessarily a problem unique to the "looping" mechanism. In other words, part of this panic may be built on a misunderstanding of the Looped Transformer mechanism itself. More notably, The Information's follow-up report stated that Anthropic and Google DeepMind are already discussing this technology—if true, this isn't just OpenAI's choice, but the entire industry probing in the same direction.

This debate didn't stay at the speculation stage. On September 3, GPT-6 Astra was officially released, and the two things that previously could only be guessed from anonymous sources and a non-denial, OpenAI now fully admitted. The official blog positions it as "the world's smartest, most aligned model": FrontierMath Tier 4 at 98%, ARC-AGI-3 at 99.9%, ExploitBench at a perfect score, with president Greg Brockman calling it a "generational leap." More crucially, on the safety half—official wording confirms Astra is the first model to cross the Preparedness Framework "Critical" cybersecurity threshold; simultaneously, the company directly admitted for the first time the most sensitive charge from the "recurrent depth" controversy—"Our evaluations find that Astra's written reasoning is harder to monitor than GPT-5.6 Sol", because "Astra has stronger control over written reasoning for simple tasks, able to solve problems with fewer written steps." The company calls this a problem they are "taking seriously," but also emphasizes that "on complex tasks, it still seems difficult to fully hide the required reasoning process." Chief scientist Jakub Pachocki's response this time was much more specific than "reaffirming monitoring as a core objective"—he offered a verifiable technical judgment: the compute graph depth of current frontier systems including Astra is still around twice that of GPT-4, with no sign of the "race toward unmonitorability" that outsiders feared.

§ 08 / CONTROL GROUP

The Mythos rumor,
and why it's not credible

The other, longer-circulating online claim—"Claude Mythos has long been using Looped Transformers"—when traced to its root, turns out to be just fan speculation based on benchmark tables, completely different in evidentiary weight from the Astra evidence in §07, and shouldn't be conflated.

Claude Mythos itself is a real product—on April 7, 2026, Anthropic officially confirmed a restricted preview (the "Project Glasswing" project, open only to partners in cybersecurity / biosecurity), which has now iterated to Mythos 5.1. But searching Anthropic's own Frontier Red Team blog post and the full product page yields not a single sentence about architecture—only usability, pricing, safety guardrails, and benchmarks. The source of the "Looped Transformer" claim was informal speculation on X based on Mythos's benchmark patterns, later turned into a PyTorch reproduction project "OpenMythos" by developer Kye Gomez (now 14.9k stars on GitHub), but the project's own README states plainly: "This is an independent, community-driven theoretical reconstruction, based entirely on publicly available research and speculation, with no affiliation, endorsement, or subordinate relationship with Anthropic or any of its proprietary systems."

Also worth correcting is a commonly reversed timeline: the University of Tokyo paper (Xu & Sato, "Should You Chain-of-Thought or Loop?", accepted at ICML 2026) that's often mentioned alongside this rumor was actually posted on arXiv in May 2025—about 10 months before the Mythos leak (March 26, 2026). The paper didn't come about because of the Mythos rumor; rather, the people later weaving this theory retroactively cited an already-existing paper. The causality is reversed.

On September 1—the same day as the Astra rumor—Anthropic simultaneously released Fable 5.1 and Mythos 5.1; the official announcement was unambiguous: "Claude Fable 5.1 and Claude Mythos 5.1 are the same model, just with different guardrail levels"; the benchmark gap is explained as "the task scope of early, lower-precision cybersecurity guardrail intervention, and with this guardrail upgrade, we expect the gap between the two models to significantly narrow." This addresses a different question, with no direct relation to "whether recurrent depth architecture is used"—but it suffices to show that the question of "whether Fable and Mythos are actually two different models," which previously could only be guessed from benchmark tables, received a blunt official answer: they were never two models, just the same weights with different levels of safety interception. This release also quietly tightened a safety clause— official documentation confirms, Fable 5.1 added new validation to the Messages API: "thinking blocks" must now exactly match the system prompt, tools, and history messages that produced them, or an error is thrown—blocking precisely a technical pathway that could be used for scaled distillation.

The Mythos "looped architecture" rumor and the Astra "recurrent depth" report are not in the same league of starting evidence—but the Astra thread has this week completed the full journey from rumor to official confirmation, while the Mythos thread remains stuck in place.

§ 09 / THE REAL BET

A warning
one year early

The real weight of this debate comes from an earlier document. In July 2025, led by Tomek Korbak, 41 researchers from OpenAI, Google DeepMind, Anthropic, the UK AI Safety Institute, METR, Apollo Research, and Redwood Research co-signed a position paper "Chain-of-Thought Monitorability: A New and Fragile AI Safety Opportunity", warning in advance that if models put more "reasoning" into continuous hidden states computed in loops, rather than generating human-readable chain-of-thought text, safety researchers' ability to observe what a model "intends to do" would fail.

Today's reasoning models at least still write intermediate steps as readable text (even if imperfectly); the Looped Transformer structure is precisely the opposite—computing more cheaply and potentially more powerfully, but with the process completely invisible. The surface of the Astra controversy is "whether OpenAI is using some architecture," but the real bet is whether what that warning described is shifting from "theoretical concern" to "happening right now."

This architectural debate has reached a阶段性 result: Looped Transformer is no longer just a parameter-saving engineering trick—it has been confirmed by OpenAI itself as standing on the AI safety red line of "whether the model's thinking process remains visible." What deserves scrutiny next is no longer "whether Astra uses recurrent depth," but "whether monitoring capability can be recovered."

§ 10 / SYNTHESIS

Four takeaways

TAKEAWAY 01

Looped Transformer is a real engineering benefit, not hype. ByteDance Seed's rigorously equalized SMELT paper proves its real benefit at large scale under compute constraints, and three real products verify this—but it simultaneously has three old problems that haven't been fully solved: optimal loop count, training instability, and latency overhead.

TAKEAWAY 02

Evidentiary weight must be assessed separately, not lumped together. The Astra thread went from anonymous sources to official admission in just two days; the Mythos thread has had no primary sources from start to finish, being purely speculation from benchmark tables. Conflating architecture guesses with official confirmations will systematically over- or under-estimate real safety risks.

TAKEAWAY 03

Chain-of-thought monitorability is not an abstract proposition; a specific threshold has already been crossed. The warning from 41 researchers a year ago now has its first officially confirmed case matching the warning's description—OpenAI directly admitted that Astra's written reasoning is harder to monitor than the previous generation. This is the first crossing from "theoretical concern" to "officially confirmed real trend."

TAKEAWAY 04

This is not just OpenAI's choice. The Information's follow-up report stated that Anthropic and Google DeepMind are also discussing "recurrent depth" technology—if true, the tension between efficiency incentives and monitoring costs will be a shared question that the entire frontier model track must squarely answer in the coming years, and it won't end with a single release.

Update Log

First published 2026-09-04