The first question every LTX 2.3 user asks after "should I upgrade" is "do my LoRAs still work?" The answer is the most carefully worded thing in the entire 2.5 release — because the two official documents say it at different risk tolerances.
The model card says: "Based on our testing, the large majority of LoRAs and IC-LoRAs trained on LTX-2.3 run on LTX-2.5 without changes. A small number of exceptions exist — validate your adapters before production use."
The GitHub README says: "Files are not interchangeable between the two models, and a LoRA only works with the model it was trained on."
Both statements are official. The reconciliation is: most 2.3 LoRAs are expected to load and run on 2.5, but compatibility is not guaranteed per-file, and the README's blanket statement is the conservative framing for anyone shipping to production. The practical rule is the one the model card gives: validate each adapter before you rely on it.
This guide covers what the 2.5 release itself ships, what carries over, and how to test your stack. Checked August 13, 2026.
The LoRAs that ship with LTX-2.5
Two official adapters come with the release, and confusing them is the fastest way to break a workflow:
1. ltx-2.5-22b-distilled-lora-450-bf16.safetensors — the distilled LoRA (mandatory in some pipelines).
The GitHub README is explicit about where it is required: the two-stage pipeline implementations that run the full (dev) model in stage 1 — all except DistilledPipeline, ICLoraPipeline, and DubItPipeline. In those two-stage flows it is infrastructure, not flavor. This is the same role the distilled-lora-384 played in 2.3, re-versioned for 2.5 (and it is the reason "a LoRA only works with the model it was trained on" bites: the 2.3 distilled LoRA does not substitute).
2. ltx-2.5-22b-ic-lora-pixel-spatial-upscaler-x2-1.0.safetensors — the detailing IC-LoRA (optional).
Hosted in its own separate repository, this is the 2x spatial detailing LoRA for DFRPipeline's refinement stage, passed via --detailing-lora. It is optional — DFR runs without it — but it is the documented path for the detail pass.
Those two are the full official LoRA set at release. Everything else is the community ecosystem migrating over — which brings us to the compatibility question.
What carries over from 2.3
The model card's statement gives the expected outcome: the large majority of 2.3-trained LoRAs and IC-LoRAs run on 2.5 without changes, with a small number of exceptions.
What that means in practice:
- Most style, subject, and IC-LoRAs from 2.3 should load on 2.5. The architecture lineage is continuous; 2.5 is not a from-scratch model (its release page calls it "a stronger foundation for what's already being built").
- Exceptions exist and are not enumerated. Neither document lists which adapters fail. "Validate your adapters before production use" is the entire protocol.
- Control-mechanism LoRAs are the highest-risk category. In 2.3, LoRAs doubled as control systems (camera, pose, HDR, lip-sync). Control adapters are more sensitive to architecture changes than style adapters — if any category has exceptions, this is the plausible one. Treat them as "must test," not "probably fine."
How to validate your 2.3 LoRA stack on 2.5
A practical test protocol, using the version-locking the README warns about:
- Inventory. List every LoRA you rely on in production: file name, base model it was trained on, and which pipeline/strength you use it at.
- Load test. Run each adapter on 2.5 with your standard prompt at your standard strength. A load failure (node error, missing key) is a definitive exception — the model card's "small number of exceptions."
- Behavior test. A successful load is not validation. Generate the same scene with and without the LoRA and confirm the adapter is actually steering output (style, identity, control) the way it did on 2.3.
- Stack test. If you stack LoRAs (a pipeline LoRA plus a subject LoRA plus an IC-LoRA), test the stack, not the components. The compatibility of the stack is what you ship.
- Document the verdict. For each adapter: pass / fail / degraded. This becomes your migration ledger — and the honest answer to "can I upgrade this weekend."
Two files you should not need to test, because they must be re-downloaded: the 2.3 distilled LoRA (replaced by ltx-2.5-22b-distilled-lora-450) and any 2.3 pipeline components (the README's "files are not interchangeable" covers checkpoints, VAEs, and encoders — not just LoRAs).
The training side: fine-tuning on 2.5
For training your own adapters, the 2.5 release adds a dedicated foundation: the LTX-2.5-Pre-Trained repository holds the pre-training checkpoint (43 GiB single-file bundle with the video VAE, audio VAE, vocoder, duration head, and text-embedding projections included) plus the matching Gemma 4 12B text encoder. The model card positions it for researchers and developers creating specialized models, fine-tuned with the standard LTX Trainer.
The main LTX-2.5 release also remains fine-tunable: the dev transformer is documented as fully trainable, and the model card notes you can reproduce published LoRAs and IC-LoRAs with the LTX-2 Trainer.
One licensing note that matters for training: the model card's license section says transfer of fine-tunes may require a paid license under the LTX-2.x Community License — relevant if you redistribute adapters trained on 2.5 (covered in our licensing guide).
Check whether 2.5 is worth the migration before you re-validate a LoRA stack. Generate with LTX 2.5 at ltx23.app — multishot and audio included — and decide on the model before you spend the weekend testing adapters.
FAQ
Do LTX 2.3 LoRAs work on LTX 2.5? The model card says the large majority run without changes, with a small number of exceptions — and tells you to validate adapters before production use. The README's conservative framing: a LoRA only works with the model it was trained on.
Is the 2.3 distilled LoRA compatible?
No. LTX-2.5 ships its own distilled LoRA (ltx-2.5-22b-distilled-lora-450-bf16.safetensors), required by two-stage pipelines that run the dev model in stage 1. The 2.3 version does not substitute.
What is the detailing IC-LoRA?
ltx-2.5-22b-ic-lora-pixel-spatial-upscaler-x2-1.0.safetensors — the optional 2x spatial detailing LoRA for DFRPipeline's refinement stage (--detailing-lora), hosted in its own repository.
Can I train LoRAs on LTX 2.5? Yes — the dev transformer is fully trainable with the LTX Trainer, and the dedicated Pre-Trained checkpoint (43 GiB) is designed for fine-tuning foundations.
Do I need to re-download pipeline LoRAs? Anything version-specific (distilled LoRA, pipeline components) must be the 2.5 version. Community style/subject LoRAs should be re-validated per the model card's guidance.
Bottom line
LTX 2.5's LoRA story: most 2.3 adapters are expected to work, none are guaranteed, and two new official adapters (the mandatory distilled LoRA for dev-based two-stage pipelines and the optional detailing IC-LoRA) are version-locked to 2.5. The migration protocol is per-adapter validation — inventory, load test, behavior test, stack test, verdict. Test the model itself first at ltx23.app so you only re-validate adapters if the upgrade is worth it.
Sources
Verified August 13, 2026 against primary documentation:
- Lightricks/LTX-2.5 — Hugging Face model card — 2.3 LoRA compatibility statement ("large majority… validate your adapters"), license note on fine-tune transfer
- Lightricks/LTX-2 — GitHub README — distilled LoRA requirement, "files are not interchangeable" / "LoRA only works with the model it was trained on", full model list
- Lightricks/LTX-2.5-22b-IC-LoRA-Pixel-Spatial-Upscaler — Hugging Face — detailing IC-LoRA,
--detailing-lorausage - Lightricks/LTX-2.5-Pre-Trained — Hugging Face — pre-training checkpoint (43 GiB), intended use, Gemma 4 encoder pairing
- ltx-trainer documentation (GitHub) — training and fine-tuning tools for LoRA, full fine-tuning, and IC-LoRA
Adapter compatibility varies per file; the model card's validation guidance is the official protocol. Licensing summaries are not legal advice.
