Liquid AI released Antidoom as open source on July 7, a surgical fix for one of the most frustrating failure modes in AI coding: doom loops, where a reasoning model starts repeating a phrase—"Wait", "So", "Alternatively"—over and over until the context window fills and the entire session is wasted.
- Original coverage: https://www.marktechpost.com/2026/07/07/liquid-ai-antidoom-doom-loops-ftpo
- Technical details: https://www.liquid.ai/blog/antidoom
- Open-source repo: https://github.com/Liquid4All/antidoom
- Trains a single token position, leaving the rest of the distribution essentially untouched—so it doesn't pollute other capabilities the way full-sequence DPO can.
- Multiple chosen tokens per sample: the model learns "any of these is fine", avoiding the common trap of swapping one over-trained token for another.
- Skips softmax, applying KL regularization in logit space, so probabilities of tokens that shouldn't change aren't inadvertently adjusted.
- Uses its own algorithm, Final Token Preference Optimization (FTPO): like DPO but with single-token training, multiple chosen tokens, logit-space KL, and more aggressive regularization.
- repetition_penalty: cheap, inference-time reweighting, but explicitly a "band-aid" that degrades other scenarios.
- RL: heavier—reward shaping and online rollouts, expensive to build and slow to tune.
- DPO: one-to-one swaps are too coarse, and full-sequence DPO makes β hard to tune.
- Multiple iterations may be needed—fixing one batch of loop onsets can expose the next.
- Both tested models are small reasoning models; effectiveness on larger closed models (e.g., Fable 5, Opus 4.7) is unverified.
- Performance degrades near temperature 1.0 (expected, since high temperature favors non-preferred tokens)—but this makes the patch ideal for low-temperature, reproducibility-focused inference, which is exactly the main coding use case.
- There is no "universal Antidoom model": it's a post-training tool, not a deliverable.
Antidoom changes no training data, involves no re-pretraining, and does not modify sampling strategy. It does exactly one thing: find the first token where a loop begins, and teach the model to choose something else at that single position.
The numbers are stark: LFM2.5-2.6B's loop rate on hard math and coding prompts dropped from 10.2% to 1.4%; Qwen3.5-4B's loop rate crashed from 22.9% to 1.0%. And it's not just trimming a long tail—overall scores went up too, because problems the model could already answer but that were blocked by loops now complete successfully.
How doom loops happen: three mechanisms conspiring
Liquid AI decomposes doom loops into three independent, compounding mechanisms:
1. Over-trained tokens plus uncertainty. Some tokens have extremely high linguistic prior probability—typically "Wait", "Alternatively", "So", "the", "But". In synthetic reasoning traces in training data, these words often signal a strategy switch. But when the model is stuck, they become the natural fallback. In LFM2.5-2.6B's loop-onset token distribution, "the" accounts for 11.39%, "So" for 4.51%, and "Alternatively" for 3.22%—this isn't thinking, it's retreating to a default channel.
2. Context reinforces the loop. Each repetition makes the model more confident about those tokens locally (a V-shaped attention pattern). Once a loop starts, stopping gets progressively harder.
3. Greedy sampling offers no exit. Reasoning models typically run at low temperature for reproducibility. Temperature 0 means always picking the most likely token; once the loop onset is locally reinforced, the model cannot escape. Even at temperature 0.67, loops persist—the problem is a polluted distribution, not sampling.
The combined effect: the model often knows the answer, gets interrupted at some moment, anxiously backtracks with "Wait", and loops to death.
How Antidoom fixes it: preference optimization on the first loop token
The approach sounds almost too simple: generate prompts that deliberately trigger loops, sample at low temperature, locate the first token of each loop, pair the "rejected token" (e.g., "Wait") with a set of chosen tokens (e.g., any of "So", "Since", "The", "Therefore"), and run preference optimization.
Several careful engineering decisions distinguish it from vanilla DPO, repetition penalties, or RL:
On an early LFM2.5-2.6B checkpoint, generating training data took ~1 hour on 8×MI325 GPUs, and training took ~1–2 hours on 1×MI325. The whole pipeline takes hours. The repo also ships a dataset, LiquidAI/antidoom-mix-v1.0, of prompts designed to trigger loops—open-sourcing the full detection, generation, and training pipeline, not just weights.
Compared to other loop fixes
Antidoom's sweet spot: you have a loop problem, you want to preserve other capabilities, and your budget is hours rather than days. You must generate a loop dataset per model—that's the limitation, and the price of not touching other capabilities.
What this fix is worth
For a coding-agent company billed by API, each broken session burns a full context window of tokens. If broken sessions can be reduced by even 5 percentage points on ~80k-token sessions, the API savings alone can cover a three-person team's quarterly salary. And Antidoom is a patch, not a new model—it can be applied post-release, somewhat like Anthropic's earlier Reveal inference hack: a corrective layer hung outside the model.
Limitations and uncertainties
Why it matters
What actually stalls engineers in AI coding today isn't SWE-bench scores—it's long-tail failures: sessions that suddenly collapse mid-run and require human takeover. Antidood-style tools address exactly that: model capability is sufficient; "not crashing at the wrong moment" is the unsolved part. If this open-source approach is validated and echoed inside the big labs, AI coding products over the next six months should see far fewer mid-session restarts.
A personal take: this is one of the few engineering paths that can visibly improve AI coding without any model upgrade. Worth trying on an internal coding agent tonight.