If you have ever watched a small reasoning model work on a hard problem, you know the moment. The chain of thought is going fine, then somewhere around token three thousand it writes "Wait, let me reconsider..." - and then it writes it again. And again. And again, until the context window is full of the same sentence and your API bill is full of garbage. This failure mode has a name now: doom loops. And as of this month it also has an open-source fix. Liquid AI released Antidoom, a training method called Final Token Preference Optimization (FTPO), and the numbers are startling: on Qwen3.5-4B the doom loop rate dropped from 22.9% to 1%. I dug through the technical report, and this is one of those small, unglamorous releases that I think will quietly improve half the small models shipped next year.
What doom loops are and why small models fall into them
A doom loop is repetitive degeneration during inference: the model emits a phrase - "Wait...", "So...", "Alternatively..." - and then keeps cycling through the same token pattern until it exhausts the context window. No answer, full context, maximum cost. It happens most often when small reasoning models meet problems at the edge of their ability, which is exactly the regime where on-device and cost-sensitive deployments live.
Liquid AI's write-up identifies three mechanisms that conspire to produce loops:
- Overtrained connector tokens plus uncertainty. Reasoning fine-tuning drills phrases like "Wait" so hard that when the model is unsure what to do next, those tokens become the safest bet - every time.
- Self-reinforcement from context. Once a phrase appears a few times in the context, the probability of emitting it again goes up. Each repetition makes the next one more likely - a feedback spiral.
- Greedy sampling at low temperatures. Deployments that want deterministic output (temperature 0, greedy decoding) remove the randomness that would otherwise let the model escape the loop by accident.
That last point matters for practitioners: the standard mitigations - repetition penalties, higher temperature - are inference-time hacks that trade one problem for another. You do not want your coding agent at temperature 1.2 just so it stops chanting "Wait".
How FTPO works: retrain one token, not the model
The elegant part of Antidoom is how little it touches. Classic preference optimization methods like DPO train on whole completions - you show the model a good answer and a bad answer and push probability mass from one to the other. That is a blunt instrument if your problem is a single recurring token decision.
FTPO - Final Token Preference Optimization - instead trains only the trailing token of a sequence that is midway through generation. Concretely: find the place where a loop starts, target the first token of the first repeat, and teach the model that at exactly this kind of junction, there are better options than starting the chant again. Everything else about the model's behavior is left alone.
A few design details from the report that I found genuinely clever:
- Multiple "chosen" tokens per sample. Instead of forcing one replacement token, FTPO spreads probability across several coherent alternatives. The model is not taught "say X instead of Wait" - it is taught "at this junction, several continuations are fine, looping is not". That avoids simply minting a new overtrained token.
- A KL-like loss computed in logit space, skipping the softmax, with two-part regularization: the targeted tokens get freedom to move, the rest of the vocabulary is constrained to stay put. This keeps the fix surgical.
- Cheap training. The recipe is LoRA at ranks 128-256, one epoch, learning rates in the 4e-6 to 2e-5 range, early stopping on a simple metric. This is a weekend job on modest hardware, not a pretraining run.
And crucially, this is not a lobotomy that trades capability for stability. Liquid AI reports that after Antidoom training, eval scores improved across the board - which makes sense once you realize every doom loop was a completion that scored zero. Stop burning attempts on loops and your benchmark numbers go up for free, especially at the low temperatures where loops were most common.
Why this matters more than another benchmark bump
I keep writing about the two directions AI is pulling in right now: giant frontier models in the cloud, and small models moving onto devices. Antidoom lands squarely in the second story, and it addresses the single biggest practical objection to it: small models are cheap, but they are flaky. A 4B model that fails 23% of the time on hard problems is not a product, no matter how fast it runs on a phone. A 4B model that fails 1% of the time starts to look like infrastructure.
This connects directly to what I wrote about Bonsai 27B squeezing 27 billion parameters into an iPhone. The on-device wave is real, but compression solves size, not reliability. The interesting trend of 2026 - and several people have made this observation - is that progress is shifting from "make the model bigger" to "systematically remove failure modes". Doom loops today; sycophancy, tool-call hallucinations and context rot are all getting the same targeted-fix treatment across the industry. It reminds me of the story I covered about "goblin mode" in GPT-5 - weird emergent behaviors stopped being funny anecdotes and became engineering targets with dedicated teams and dedicated methods.
The other reason to care: everything is open. The code is on GitHub (Liquid4All/antidoom), the training data mix (LiquidAI/antidoom-mix-v1.0) is on Hugging Face, and the method was demonstrated on someone else's model - Qwen3.5-4B - not just Liquid's own LFM checkpoints. That last detail is what separates a research flex from a contribution. Anyone shipping a small reasoning model - and after Qwen, Bonsai and the flood of on-device deployments, that is a lot of teams - can apply this recipe this week.
The caveats worth keeping in mind
To be fair to reality, a few grains of salt. The headline numbers come from Liquid AI's own evaluation, under greedy sampling, on two models - independent replications will tell us how well the recipe generalizes across architectures and training mixes. The method fixes one specific failure mode: a model that loops 1% of the time can still be wrong in all the ordinary ways. And there is a philosophical wrinkle I keep chewing on: doom loops are partly a symptom of a model recognizing it is stuck. Training away the symptom does not grant the ability the model was missing - ideally you want the model to escape the rut and still know it is in one.
None of that undercuts the release. It just means Antidoom is a reliability patch, not a capability upgrade - and the industry needs both.
If you want to try it yourself
The practical on-ramp is short. Clone the repository from GitHub, grab the antidoom-mix-v1.0 dataset from Hugging Face, and point the training script at your model checkpoint. The published recipe - LoRA rank 128-256, a single epoch, learning rate between 4e-6 and 2e-5, early stopping at chosen_win=0.35 - fits on a single decent GPU for models in the 2-8B class. Before training, it is worth measuring your own baseline: run your eval set at temperature 0 with greedy decoding and count completions that hit the context limit while repeating a phrase. That number is your doom loop rate, and in my experience most teams shipping small models have never actually measured it. If it comes back above a few percent, an afternoon with FTPO is probably the cheapest reliability win available to you this quarter.
Summary: unsexy fixes are the story of 2026
Antidoom will not trend the way a frontier model launch does. There is no benchmark chart with a new king, no demo video. Just a targeted training method, open code, open data, and one obnoxious failure mode reduced from 22.9% to 1% on a model everyone can download. But if you zoom out, this is what the maturing of AI actually looks like: less alchemy, more engineering; fewer miracle models, more systematic removal of the reasons models embarrass themselves in production. For those of us building on small and on-device models, this is the kind of release that changes what you can ship. I will take a 20-point reliability improvement over a 2-point benchmark improvement every single time.
Sources: Liquid AI, MarkTechPost.