Liquid AI Antidoom·FTPO Commentary: Why infinite loop inference model requires measuring loop start token and exit rate before prompting

1. One-line problem definition

Key line: Infinite repetition of the inference model is not an answer quality problem, but a runtime failure mode that destroys operational costs and reliability at the same time.

Liquid AI explained in Antidoom, released on July 7, 2026, that the phenomenon in which the reasoning model repeats expressions such as "Wait", "So", and "Alternatively" and fails to end with a normal answer is a doom loop. AI Times reported this on July 8, 2026, and reported that 10.2% of difficult math and coding problems at the initial checkpoint of LFM2.5-2.6B showed doom loops.

The scope of application of this article is a small inference model, an in-house fine-tuning model, and a work automation system that requires stable answers at low temperature. This is not an article that deals with simple chatbot speech improvement, creative writing diversity, and general hallucination prevention.

2. First, conclusion

Key line: Antidoom is not a prescription to be applied to all models, but a narrow and strong repair tool that is only used on models with measured repetitive loops.

Recommended target is a team that learns its own model or operates a LoRA adapter and actually accumulates repeated answers in the failure log. It is especially worth considering if the model is a service that generates long intermediate thought processes, such as math solving, code generation, or long-step reasoning.

On the other hand, teams that only call closed models through API, teams that do not have a learning pipeline, and teams that have not yet measured the repetition rate are better off applying an output length limit, repetition detector, fallback model, and retry policy before antidoom learning.

3. Decomposition of core structure

Key line: The point of Antidoom is not to reteach the entire answer, but to find the token position where the loop begins and change the selection at that one point.

The structure can be viewed in four steps. First, we generate model responses as a set of prompts that can intentionally lead to loops. Second, sections that are repeated over a certain length are detected in the generated results. Based on the official README, the basic detection settings set the following conditions: minimum 4 repetitions, minimum 60 character repetitions, and maximum period 1024.

Third, the first token where repetition begins is marked as a rejected token, and a more natural replacement token is selected at the same location as the chosen token candidate. Fourth, learn the LoRA adapter with Final Token Preference Optimization, or FTPO. FTPO, as the name suggests, is a preferred optimization that only adjusts the final token selection during creation.

If we compare it to the standard of a novice developer, rather than rewriting the entire text, it is a method of drawing a red pen on the first word where the sentence starts to slip and telling the model, “Choose one of these words instead of this word.”

4. Description of design intent

Key line: Antidoom is not learning that increases the knowledge of the model, but distribution repair that prevents the inference ability we already have from being trapped in repeated tokens.

It is clear why Liquid AI did not relearn all correct answers. A doom loop is a failure that is closer to “choosing the next token reinforces itself” than to “don’t know the problem.” Therefore, additional supervised fine-tuning with the correct answer data may have an unnecessarily wide impact.

Antidoom moves only around the rejected token and chosen token, and ties the remaining vocabulary distribution close to the standard model. What you get is rapid mitigation of narrow failure modes. Giving up is versatile. It is not an all-purpose safety device that solves hallucinations, incorrect reasoning, and tool call failure all at once.

5. Evidence and Comparison

Key line: Looking at the published results alone, Antidoom is strong against repeated loops, but the benchmark and loop rate before and after application must be verified together.

Liquid AI announced that the doom loop rate was reduced from 10.2% to 1.4% at the LFM2.5-2.6B initial checkpoint. Qwen3.5-4B also explained that it decreased from 22.9% to 1% based on a greedy sampling environment. In addition, it was suggested that the LFM2.5-2.6B standard data generation took about 1 hour on eight AMD MI325 GPUs, and that additional learning took 1 to 2 hours on a single MI325 GPU.

6. Actual operation flow and step-by-step execution method

Key line: The introduction order is not learning, but measurement, reproduction, small adapter training, and regression verification.

First, collect repeat failure samples from the operation log. Cases where the same sentence or the same semantic unit is repeated four or more times and the answer is not completed properly are stored separately as JSONL. Next, calculate the baseline loop rate. For example, if 80 out of 1,000 inferential prompts are repeating loops, the starting point is 8%.

The quick start based on the official repository is the following 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

NVIDIA/CUDA follows the default `uv.lock` and `configs/default.yaml` paths. For AMD/ROCm, CUDA lock should not be used as is, but `configs/default_amd.yaml` and `uv run --no-sync` should be used as instructed in README. If this difference is ignored, it is easy to mistake environmental problems for model problems.

Be sure to leave three numbers before applying the operation. Baseline loop rate, loop rate after applying antidoom, and general quality evaluation score. If only the loop rate decreases and the accuracy decreases, it is not a success.

7. Mistakes and Pitfalls

Key line: Antidoom's biggest risk is creating new repetitions in other tokens when you thought you had eliminated repetitions.

Plot 1: The repetition detection criteria are lax. If you loop through normal code blocks, tables, and lists, you learn incorrect rejected tokens. Precautions include having a minimum number of repetitions, minimum repetition length, and manual sample inspection of at least 50. Recovery involves discarding incorrectly mined pairs and re-fixing the detection criteria.

Trip 2: Excessively suppress only certain words. If “Wait” often starts loops, viewing all “Wait” as bad tokens will ruin the reasoning trace. This is why Antidoom README emphasizes regularization of rejected·chosen token distribution.

Trap 3: Judging that one round of learning is done. Liquid AI explains that multiple rounds can be helpful as new loops may be revealed in other tokens after one application. However, as the number of rounds increases, regression testing must also increase.

Trap 4: Trying to solve it by just raising the temperature. High temperature can sometimes create a way out, but it can still be repeated when the loop token probability is already very high. Liquid AI results also explain that a significant loop remained at temp 0.67.

8. Strengths and Limitations

Key line: Strength is narrow math, limitation is narrow math.

The strength is that the location of failure is clear. Antidoom focuses on “let’s fix this iteration start token” rather than “let’s make the model smarter”. So there is room for quick experimentation with LoRA adapters without significantly changing the overall model characteristics.

The limit also comes from the same point. It cannot be directly applied to closed API models. Additionally, separate evaluation and guardrails are required for incorrect answers, source manipulation, tool call failure, and security policy violations that are not repeat loops. In terms of cost, it requires data generation at the level of 20k preference rows and a GPU environment, so it may be excessive for small-scale services to attach from the beginning.

9. Points to study more deeply

Key line: To properly understand Antidoom, you need to look at iterative generation problem, preference optimization, and serving temperature together.

The first is neural text degeneration. This is a classic problem of explaining why a language model repeats the same expressions. The second is the difference between DPO and FTPO. DPO is closer to response-level preference optimization, while FTPO targets specific token selection during creation. The third is the duality of low temperature operation. Creates a stable answer, but reduces the escape room for incorrectly reinforced tokens.

When viewing the source code, the order of `src/antidoom/repetition.py`, `src/antidoom/ftpo_data.py`, and `src/antidoom/ftpo_train.py` is good. The pros and cons of this method become clear when we see how detection, data row generation, and training loss follow.

10. Implementation checklist and author's perspective

Key line: The operations team should treat Antidoom as a failure mode removal project, not a model improvement project.

• Have you calculated the repeat loop rate from the last 1,000 or more speculative requests?
• Has the repetition detection criteria been reviewed to distinguish them from normal repetitions such as codes, tables, and lists?
• After applying baseline, was the evaluation set of the rollback model executed under the same conditions?
• Did you also record accuracy, exit rate, average number of tokens, and latency along with loop rate reduction?
• Have you prepared a deployment switch that can immediately disable the LoRA adapter?
• Have you created a second round evaluation queue to see if a new loop token appears?

Definition of Done: In the same evaluation set, it is considered complete when the iterative loop rate is reduced by more than 80% and the key indicators of accuracy, completion rate, and average delay time remain within the acceptable range.

From the author's perspective, Antidoom is much more practical than the "just use prompts well" prescription. However, there is no need for all teams to start learning right away. We recommend creating a detector and log system first, and then adding antidoom when iterative loops are confirmed to be a real cost problem.

Reference material

• AI Times, Liquid AI, reveal 'anti-doom' training technique to catch inference model 'infinite loop', 2026-07-08
• Liquid AI, Reducing Doom Loops with Final Token Preference Optimization, 2026-07-07
• Liquid4All/antidoom GitHub Repository, released on 2026-07-07
• LiquidAI/antidoom-mix-v1.0 Hugging Face Dataset, updated 2026-07-07
• Direct Preference Optimization: Your Language Model is Secretly a Reward Model, 2023
• The Curious Case of Neural Text Degeneration, ICLR 2020