A free lunch that is not free
Looping is the trick of re-applying a block of a model’s layers so that every token passes through it more than once. Its appeal is accounting: the parameter count does not change, so the file on disk, the memory footprint and the training cost all stay where they were. A paper posted to arXiv on 30 October points out what that accounting leaves out.
Every generated token pays the loop. Re-applying m of N layers makes each token roughly (N+m)/N times as expensive to produce. A loop that a model learns during large-scale pretraining earns that price. Whether a loop bolted onto an already-trained model earns it is the question the paper sets out to settle.
Two baselines, not one
The design is the argument. The authors compare a looped model against two things, rather than against nothing.
The first is the same model trained identically without the loop — an equal-parameter comparison, which asks whether the loop adds anything a plain model of that size does not already have. The second is the best unlooped use of the same inference floating-point operations — an equal-FLOPs comparison, which asks whether the compute the loop spends would have been better spent some other way.
A looped model has to beat both to be worth adding. Most reported gains from looping are measured against only the first.
Only the smallest model wins
The sweep covers Qwen3 and Qwen3.5 models from 0.8 billion to 9 billion parameters. Across that range, only the looped 0.8B model beats both baselines.
At 4B and 9B the looped model does not even beat the first baseline: the same model, trained the same way, without the loop. Adding the loop after pretraining made it worse, at a higher per-token cost.
Not a ceiling effect
The obvious objection is that the benchmarks were saturated — that there was nothing left for the loop to win. The authors close that off directly. On the same benchmarks, the unlooped 9B model scores up to 13 points higher than the unlooped 4B model, which means the tasks still discriminate between capability levels at that scale. The headroom exists; the loop does not reach it.
The narrow case that survives
The conclusion is specific rather than sweeping: introducing loops into an already pretrained model pays only for small models operating under a fixed parameter budget. That is a real deployment regime — an on-device model that cannot grow its weights but can spend more compute per token — and it is much narrower than the way looping is usually pitched.
What to watch
The paper says nothing about loops learned during pretraining, which it explicitly treats as justified. The open question is where the crossover sits and why: the result at 0.8B and the result at 4B are different in kind, not degree, and the paper does not identify the mechanism. Watch for a follow-up that tests the boundary between them, and for whether anyone reports looping gains against an equal-FLOPs baseline rather than an equal-parameter one.
