LoopCoder-v2 is out 🚀

Loop Transformers reuse the same block for recurrent hidden-state refinement — letting models “think” more without simply stacking more layers.

We study how many loops are actually worth it in Parallel Loop Transformers.

📜https://t.co/6iKMPelqQ2 https://t.co/Lu7qZskNYW

Paper page - LoopCoder-v2: Only Loop Once for Efficient Test-Time Computation Scaling

Source: https://huggingface.co/papers/2606.18023 Published on Jun 16

#1 Paper of the day Authors:

,

,

,

,

,

,

,

,

,

,

,

,

,

,

,

Abstract

Parallel loop Transformers achieve better code generation performance with two loops due to refined representations, while additional loops cause diminishing returns and increased positional mismatch costs.

Looped Transformersscale latent computation by repeatedly applying shared blocks, but sequential looping increases latency and KV-cache memory with the loop count.Parallel loop Transformers(PLT) alleviate this cost throughcross-loop position offsets(CLP) andshared-KV gated sliding-window attention, making loop count a practical design choice. We therefore study PLTloop-count selectionthrough a gain--cost view: an extra loop may refine representations, but CLP also introduces a positional mismatch at each loop boundary. We instantiate this study by trainingLoopCoder-v2, a family of 7B PLT coders with different loop counts, from scratch on 18T tokens, followed by matchedinstruction tuningand evaluation. Empirically, the two-loop variant delivers broad gains over the non-looped baseline across code generation, code reasoning, agentic software engineering, and tool-use benchmarks, improvingSWE-benchVerified from 43.0 to 64.4 points andMulti-SWEfrom 14.0 to 31.0 points. In contrast, variants with three or more loops regress, revealing a strongly non-monotonic loop-count effect. Our diagnostics show that loop 2 provides the main productive refinement, while later loops yield diminishing, oscillatory updates and reduced representational diversity. Because the CLP-induced mismatch remains roughly fixed as refinement gains shrink, the offset cost increasingly dominates. This gain--cost trade-off explains PLT’s saturation at two loops and provides diagnostics forloop-count selection.

View arXiv pageView PDFAdd to collection

Get this paper in your agent:

hf papers read 2606\.18023

Don’t have the latest CLI?curl \-LsSf https://hf\.co/cli/install\.sh \| bash

Models citing this paper0

No model linking this paper

Cite arxiv.org/abs/2606.18023 in a model README.md to link it from this page.

Datasets citing this paper0

No dataset linking this paper

Cite arxiv.org/abs/2606.18023 in a dataset README.md to link it from this page.

Spaces citing this paper0

No Space linking this paper

Cite arxiv.org/abs/2606.18023 in a Space README.md to link it from this page.

Collections including this paper2