Why the Old Fixes Only Treat the Symptom

Before Antidoom, dealing with doom loops usually meant one of two routes, each with its own drawback.

The first is applying repetition_penalty at inference time, which temporarily suppresses the probability of words that have already appeared. It's like a band-aid — no retraining needed — but it suppresses indiscriminately and can drag down the quality of otherwise normal output too. The second is reinforcement learning (RL), which can target loops specifically, at the cost of carefully designed reward signals and expensive online rollout sampling.

Change One Token, Leave Everything Else Alone

Antidoom narrows the scope of the fix down to the extreme.

It first locates the single token where the doom loop begins, and trains the model — only at that position — to choose a more coherent alternative. The probability distribution over the rest of the vocabulary stays almost exactly as it was. The model's overall output habits are untouched; the patch lands precisely on the seam that triggers the loop.

Where Doom Loops Come From: Three Forces Stacking Up

Behind the doom loop are three mechanisms acting at once.

Mechanism 1: Overtrained High-Frequency Words Meet Model Uncertainty

Some words are simply more likely to get picked. Well-known examples elsewhere in the industry include "delve" and "testament" — one possible cause is synthetic data pushing their frequency higher than how humans actually write. In reasoning models, this class of high-frequency word is often something like "Wait" or "Alternatively" — words that bridge steps or signal self-reflection. They're not bad in themselves; they can mark a pivot in strategy or a verification step. But once the model gets stuck and isn't sure what comes next, they become a convenient fallback, restarting the same chain of reasoning from scratch all over again.

On the early LFM2.5-2.6B checkpoint, the words that most often trigger a doom loop (share of all loop starting points):

Mechanism 2: Repeated Context Reinforces Itself

A sequence that has appeared earlier makes that same sequence more likely to appear again later. Every repetition nudges the probability of each token in that phrase closer to 1, snowballing until it can't stop. Research by Duan et al. links this to a "V-shaped" attention pattern, and finds that semantic repetition — the model stuck on the same idea — actually precedes literal, word-for-word repetition.

The probability of each token in a loop being selected again climbs toward 1 as repetitions accumulate, forming a self-reinforcing cycle. Source: Liquid AI

Mechanism 3: Low-Temperature Sampling Leaves No Way Out

Reasoning models generally run at very low sampling temperatures, to keep the reasoning process stable and reproducible. (Sampling temperature controls how willing the model is to pick less-likely words when choosing the next one: low temperature means it almost always picks the single most probable word; high temperature means it's more willing to try lower-probability words.) At temperature 0, it always picks the single most-likely word, so once a loop has been reinforced, there's no exit. In theory, raising the temperature should help — but once Mechanism 2 has pushed the loop token's probability up near 1, there's barely any probability left for other words, so even a high temperature still gets stuck; official data shows clear looping even at temp=0.67. The lower the temperature, the worse the doom loop.

How to Find the Problem Token — and How to Train It

Fixing doom loops first means turning them into trainable data.

The process: use a prompt set specifically designed to induce loops (LiquidAI/antidoom-mix-v1.0), generate a large volume of the model's outputs at low temperature, then mine the failed samples out of that batch. A passage is counted as a doom loop if it repeats at least 4 times and is at least 60 characters long — two thresholds chosen to avoid both false positives and false negatives. Once a loop is found, the first token of the first repetition is locked in and labeled rejected (the one that shouldn't have been picked). At that same position, the model's own top-k candidates are pulled, noise that's too short or non-alphanumeric is filtered out, and up to 20 reasonable alternatives are kept as chosen (the better options). Each training example is a triple like this: preceding context, one rejected token, one or more chosen tokens.

A sample of doom-loop training data: locating the first token of the first repetition in a failed output and labeling it rejected. Source: Liquid AI

Before training, the chosen and rejected distributions also need a regularization pass. Otherwise high-frequency words like Wait, So, and the would dominate the entire training process — and suppressing them too aggressively would, in turn, hurt the model's reasoning ability.

How FTPO Differs from DPO

FTPO (Final Token Preference Optimization) is a DPO-like preference optimization algorithm, but it's designed from the ground up to "touch only a handful of tokens and disturb as little of the rest of the model as possible." Compared with DPO, it differs in four ways:

How Long to Train, and When to Stop

The scale of this training is surprisingly small.

It fine-tunes with LoRA (a patch-style fine-tuning method for large models — instead of retraining every parameter, it trains a small set of newly inserted parameters, which is cheap and disturbs the base model less), usually for just one epoch. Empirically, a LoRA rank of 128 to 256 works best: enough capacity to learn, small enough to limit side effects; training covers all attention layers, MLP layers, plus lm_head; the learning rate sits roughly between 4e-6 and 2e-5.

How do you know when to stop? Use chosen_win as the early-stopping criterion — it measures, at the doom-loop starting position, what share of the time the model now prefers one of the "better alternatives" over the original word that tended to trigger the loop. Stopping around chosen_win=0.35 typically brings the doom-loop rate down from 20-30% to 1-2%. Overtraining tends to create new doom loops elsewhere instead.

How cheap is it? Taking the early LFM2.5-2.6B checkpoint as an example: generating the training set takes about 1 hour (8 MI325 GPUs), and training itself takes 1 to 2 hours (1 MI325 GPU). Generation stops once it accumulates 20,000 sample pairs.

The Code Is Open — You Can Run It Yourself

The whole method is fully open-source, and anyone can reproduce it by following along.

The generation, detection, and FTPO trainer code are all on GitHub (Liquid4All/antidoom), with a full hyperparameter guide in the README. The prompt dataset it uses, LiquidAI/antidoom-mix-v1.0, is pure prompts — deliberately stripped of ground-truth answers, reasoning traces, hidden tests, and answer labels. Its only job is to induce doom loops, not to teach any new knowledge.

That means any team with a reasoning model in hand can, in theory, run the same pipeline on their own model, without needing to pretrain from scratch. Once the environment's set up, a single command runs the full "generate plus train" flow:

git clone https://github.com/Liquid4All/antidoom
cd antidoom
uv sync

uv run antidoom -c configs/default.yaml -r runs/antidoom1 \
  --temp 0.01 \
  --model-name LiquidAI/LFM2.5-1.2B-Base

It's not locked to NVIDIA either. Antidoom also runs on AMD Instinct MI-series GPUs (ROCm), giving teams without N-series cards a path forward.

Results: Both Models' Doom-Loop Rates Down to Around 1%

After training, both models' doom-loop rates were pushed down to around 1%.

The early LFM2.5-2.6B checkpoint went from 10.2% to 1.4%, with eval scores improving across the board. That improvement comes entirely from fewer doom loops — the training set doesn't teach any new math or coding knowledge. It just removes the obstacle that had been standing between the model and the answers it could already reach. Qwen3.5-4B saw an even bigger effect, dropping from 22.9% to 1% under greedy sampling, with eval scores jumping substantially.

Doom-loop rate before and after training. Source: Liquid AI

An Unexpected Discovery: Higher Temperature Isn't Always Smarter

Training also turned up a counterintuitive result on the side.

Conventional wisdom has long held that reasoning models should use a higher sampling temperature, to let them explore solutions more broadly. But after Antidoom training, both models actually performed worse at temp=1.0. The reason isn't complicated: before training, scores in the low-temperature range were being dragged down by doom loops; once the loops were cleared out, the low-temperature range — close to greedy sampling — actually scored the highest. The old "higher temperature is better" folk wisdom was likely just doom loops being partially masked at higher temperatures, mistaken for a genuine benefit of temperature itself.

Both models trace out the same pattern: before training, scores in the low-temperature range were pulled down by doom loops; after training, the low-temperature range is optimal, with a slight dip near temp=1.

Early LFM2.5-2.6B checkpoint: eval score versus sampling temperature, before and after training. Source: Liquid AI

Qwen3.5-4B: the same pattern — the biggest gains are in the low-temperature range, with a slight dip after training near temp=1. Source: Liquid AI

In practice, you can also run Antidoom for multiple rounds. After the first round suppresses the loop-prone words, new problems can surface: some other tokens now become the new starting points for loops. Running another round, targeted at those newly emerged loops, can push the doom-loop rate down even further.

On July 7, 2026, Liquid AI released and open-sourced Antidoom, a training method built specifically to fix doom loops.

Before it, there were only two routes: apply repetition_penalty at inference time (a switch that temporarily downweights words that already appeared) — a band-aid that can drag down normal output too; or retrain with reinforcement learning (repeatedly training the model with reward/penalty signals) — expensive and hard to tune. Antidoom took a different approach: instead of touching the whole model, it trains just "the single word where the doom loop starts."

But how can changing just one word fix the whole problem? First you need to see where doom loops actually come from.

A doom loop isn't a random glitch — it's three forces stacking up.

① Some high-frequency words (the, So, Wait, and the like) become a convenient "fallback option" whenever the model is stuck and unsure what comes next; ② every repetition pushes that phrase's probability of being picked again closer to 1, reinforcing itself; ③ reasoning typically uses low-temperature sampling (almost always picking the single most-likely word), so once a loop forms there's no way out. What Antidoom does is find that very first word that pulls the whole passage into a loop, and retrain just that one slot's probability, spreading it across a few more coherent alternatives — leaving the other tens of thousands of words untouched.

Picture asking the model to solve a hard math problem — it's already repeated "Wait" a dozen times, and the context is nearly burned out:

Put in everyday terms: out of 100 hard problems, how many get stuck in a doom loop and waste all that compute for nothing.