LTX-2.5 has no reference/identity template, and an Ingredients IC-LoRA for it shipped 2026-09-10

[dkackman]

tool/endpoint: templates/ltx2/* — the LTX-2.5 family has no reference/identity template

repro: list_workflows(shape="shot") over the LTX-2.5 family. Eight templates; none accepts a
subject reference. The ltx-2.5 skill states it outright: "No template in this family takes a
user-supplied video, so a user's own footage is not a fit for any of them."

expected: parity with what the H3 family offers — some way to hold a subject's appearance
across a generation.

actual: there is no LTX equivalent of templates/minimax/reference-to-video. Identity in the
LTX family can only be pinned through a first/last frame image.

what's now available: Lightricks shipped
LTX-2.5-22b-IC-LoRA-Ingredients
on 2026-09-10 — multi-reference conditioning, file ltx-2.5-22b-ic-lora-ingredients-0.9.safetensors.
On the 2.3 line the same IC-LoRA is the most-pulled of the family by a wide margin (7,103
downloads / 196 likes vs. a few hundred for most others), which is at least weak evidence it
earns its keep.

why this is cheap: the plumbing already exists. templates/ltx2/generative-upscale already
drives an IC-LoRA through
diffusers.pipelines.ltx2.pipeline_ltx2_ic_lora.LTX2ReferenceCondition with an ic_lora step,
and the Lightricks/LTX-2.5-Diffusers card confirms IC-LoRA workflows go through the modular
pipeline's reference_conditions= parameter. So this is a template plus a prompt, not engine
work — unlike the H3 items in #147/#148/#149, which are blocked on exposing new variables.

caveats, stated up front:

• The weight is 0.9, a preview. Of the eight new 2.5 IC-LoRAs only Clean-Plate is 1.0.
• The repo is gated: auto. lem evidently already has HF access (it pulls the Pixel-Spatial-
  Upscaler fine), so this should not block — but I could not read the card unauthenticated, so
  the exact reference format it expects is unverified. That is the first thing to check.

related: full LTX-2.5 research write-up, including the other seven IC-LoRAs and what was ruled
out, is in the comment below.

[dkackman]

LTX-2.5 — what changed since the dw templates were built

Research date 2026-09-14, same scope as the H3 pass. dw's LTX templates and their audit date
from 2026-09-07 (docs/proposals/audits/2026-09-07-ltx-2.5-audit.md).

The headline is different from H3's. For H3 the pinned LoRA was a generation behind. Here the
opposite: dw is current on the one checkpoint it pins, and the LTX-2 code has not moved
since before the audit. What moved is the model side — Lightricks shipped an entire LTX-2.5
IC-LoRA family on 2026-09-10 that dw does not use at all.

Reddit remains unreachable from this session, same as the H3 pass. The new IC-LoRA repos are
gated: auto, so their cards could not be read unauthenticated — lem clearly already has
access (it pulls the upscaler fine), so gating is not a blocker, but per-LoRA conditioning
formats are unconfirmed below where noted.

---

1. The upscaler dw pins is current — verified, not assumed

templates/ltx2/generative-upscale pins:

Lightricks/LTX-2.5-22b-IC-LoRA-Pixel-Spatial-Upscaler
  ltx-2.5-22b-ic-lora-pixel-spatial-upscaler-x2-1.0.safetensors

That repo's lastModified is 2026-09-14T06:26Z — today, which looked alarming. It is not:
the repo still contains exactly one .safetensors, the same x2-1.0 file dw already names. The
touch was card/metadata, not a new weight. No action.

2. The LTX-2 engine has not moved since before the audit

Latest release is 1.3.0 (2026-08-25); latest commit on main is also 2026-08-25. So the
audit's engine-side reading is still current, and nothing in the skill's "Hard rules" is stale.

Worth carrying forward from 1.3.0 anyway, because two items bear on templates dw already has:

• Keyframe-aware diffusion-VAE decoding — "sharpens detail at the frames a generator anchored
  on", via VideoDecoder.decode_video(..., keyframes=). Directly relevant to
  templates/ltx2/keyframes. Needs a keyframe-trained video VAE; older checkpoints decode as
  before. Open question: this is an ltx_pipelines API, and dw runs diffusers — whether
  diffusers exposes an equivalent is unverified.
• Decode tiling fixes — automatic tiling "no longer OOMs in colour conversion on clips that
  looked like they had spare VRAM"; the budget now reserves encoder memory per chunk. Same
  caveat about which runtime it lives in.

Also in 1.3.0, for the record: PipelineOutput replaced tuple returns (breaking for direct
callers), DFR switched to --distilled-checkpoint-path, and --temporal-upsample-rounds became
--temporal-upscalings.

---

3. Eight LTX-2.5 IC-LoRAs shipped 2026-09-10; dw uses none of them

Repo (Lightricks/…)	File	Ver
LTX-2.5-22b-IC-LoRA-Clean-Plate	…clean-plate-1.0.safetensors	1.0
LTX-2.5-22b-IC-LoRA-Ingredients	…ingredients-0.9.safetensors	0.9
LTX-2.5-22b-IC-LoRA-Deblur	…deblur-0.9.safetensors	0.9
LTX-2.5-22b-IC-LoRA-Decompression	…decompression-0.9.safetensors	0.9
LTX-2.5-22b-IC-LoRA-Colorization	…colorization-0.9.safetensors	0.9
LTX-2.5-22b-IC-LoRA-Day-To-Night	…day-to-night-0.9.safetensors	0.9
LTX-2.5-22b-IC-LoRA-Water-Simulation	…water-simulation-0.9.safetensors	0.9
LTX-2.5-22b-LoRA-Cinemagraph (plain LoRA, not IC)	…cinemagraph-0.9.safetensors	0.9

Maturity caveat, stated up front: everything except Clean-Plate is 0.9, i.e. a preview
weight. That argues for adding one or two deliberately and measuring, not porting the set.

The important part: dw already has the plumbing. generative-upscale already drives an
ic_lora step through
diffusers.pipelines.ltx2.pipeline_ltx2_ic_lora.LTX2ReferenceCondition, and the LTX-2.5-Diffusers
card confirms IC-LoRA workflows go through the modular pipeline's reference_conditions=
parameter. So each of these is a template plus a prompt, not engine work — a much cheaper
proposition than the H3 items.

The biggest gap is Ingredients

Ingredients is multi-reference conditioning — the LTX line's answer to identity/subject
consistency. dw's LTX family currently has no reference or identity template at all; the
skill states outright that no template in the family takes user-supplied footage, and there is no
LTX equivalent of H3's reference-to-video. On the 2.3 line Ingredients is also by far the
most-pulled IC-LoRA (7,103 downloads, 196 likes), which is some evidence it earns its place.

Deblur and Decompression are the ones that bear on today's complaint

Both are restoration passes. The problem that started this session was a grainy, mushy background
at 544p. A Deblur or Decompression pass over a cheap low-res render is a different trade from
re-rendering at higher resolution — worth measuring against the two-stage refine, which is
currently the only sharpening route the family has.

---

4. The 2.3 line still has capabilities not ported to 2.5

Present on LTX-2.3-22b-* and absent from 2.5 as of today: Foley-V2A, Relight,
In-Outpainting, HDR, DubIt, Instant-Shave, Cross-Eyed, Motion-Track-Control,
Union-Control.

Foley-V2A is the one to watch. The skill notes LTX audio is generated in the first pass and
"nothing refines it" — a V2A LoRA is exactly the missing re-score path. But it is 2.3-only, and
mixing checkpoint lines is not a drop-in. This is a watch item, not a recommendation.

---

5. dw decodes with the conv VAE; a diffusion VAE decoder exists

templates/ltx2/two-stage builds on LTX2Pipeline + LTX2LatentUpsamplePipeline. Nothing in
the family references LTX2VideoDiffusionDecodePipeline, which the LTX-2.5-Diffusers card lists
as an alternative decoder.

Upstream treats the DiffVAE decode as the production path, with a backend ladder where NATTEN
is "the fastest production path on non-B200 GPUs (Hopper/Ampere/Ada)" — which is this box.
Their warm-runtime figures show how much the backend matters: chunked_eager is roughly
2–2.5× slower than combined_compile.

Caveat: those specific knobs are ltx_pipelines flags. In diffusers the question is simply
whether calling the diffusion decode pipeline is worth its cost over conv decode. This is an
experiment to run, not a settled win — but it is the cheapest untested quality lever in the
family, since it changes only the decode.

---

6. DFR is upstream's recommended production path, and dw uses none of it

Lightricks' own pipeline-selection decision tree routes "Production quality / higher fps →
DFRPipeline", and marks the one-stage pipeline as "primarily for educational purposes". DFR is
what carries spatial + optional temporal 2×/4× upscaling and the higher effective frame rates —
the 48/96 fps path the skill already notes "belongs to the DFR pipelines, which no template here
uses yet."

1.3.0 additions there: a tiled spatial epilogue so 4K finishes without denoising the full canvas
(--spatial-upscalings 2, and use 3840x2176 — 3840x2160 is not on the size grid), a
multi-GPU runner, and fps snapping to 60 whenever playback fps exceeds 30 so 48/50 stay in the
trained range.

The honest framing: DFR lives in ltx_pipelines, not diffusers. Adopting it means standing up
a second runtime beside the diffusers path everything else uses. That makes it simultaneously the
largest quality lever available to this family and by far the most expensive item on this list —
a design call, not a template change.

---

7. Quantization: NVFP4 is not for this hardware. Confirmed.

get_memory reports the device as an NVIDIA GeForce RTX 3090 (24,122 MB) — Ampere, SM 8.6.

• LTX-2.5 ships diffusion_models/ltx-2.5-22b-distilled-transformer-nvfp4.safetensors, and
  there are LTX-2.3-nvfp4 / LTX-2.3-fp8 repos. Tempting on a 24 GB card.
• NVFP4 requires Blackwell (SM ≥ 10) plus ltx_kernels.nvfp4. A 3090 cannot use it, cast or
  prequant. Don't chase it.
• FP8 has no native support pre-Ada either; upstream's fp8-cast works by casting (1.3.0 fixed a
  crash with LoRAs on "pre-Ada GPUs such as RTX 3060 or A100"), so it buys memory, not math.
• dw already quantizes the transformer to {uint4} and the text encoder to {int8} via SDNQ,
  which is more aggressive than either. Most likely nothing to gain here — recorded so the
  next person doesn't re-investigate it.

Not ruled out: torch.compile. Upstream compiles transformer blocks shape-polymorphically
(one artifact serves any token count) and reports it as a real speedup; diffusers supports
torch.compile too. Untested here, and compile time has to be amortised across a run, but it is
hardware-agnostic and worth measuring.

---

Recommendations, in order of value-for-effort

1. Nothing on the upscaler — verified current as of today. Close the question.
2. Add an Ingredients template. Biggest capability gap in the family (no reference/identity
   path exists at all), and the IC-LoRA plumbing is already in generative-upscale. Note the
   weight is 0.9.
3. Try Deblur and/or Decompression as a restoration step. Cheap, and it addresses the
   quality complaint class directly. Measure against the two-stage refine rather than assuming.
4. Experiment with the diffusion VAE decoder on two-stage. Only the decode changes; NATTEN
   is the right backend on Ampere.
5. Measure torch.compile on the transformer.
6. Watch for a 2.5 port of Foley-V2A — it is the missing audio-refinement path.
7. Decide about DFR deliberately. Upstream's production path, a second runtime to adopt.
8. Skip NVFP4/FP8. Ruled out on a 3090; SDNQ uint4 already goes further.

Sources

• Lightricks on Hugging Face — model list and dates
• Lightricks/LTX-2 CHANGELOG — 1.3.0, 2026-08-25
• pipeline-selection.md — DFR as production path
• optimization.md — quantization policies, DiffVAE backends, compile
• Lightricks/LTX-2.5-Diffusers — pipelines, reference_conditions=, distilled sigmas
• HF model APIs for the LTX-2.5 IC-LoRA repos (file lists, versions, dates, gating)
• dw itself: get_workflow on templates/ltx2/{text-to-video,two-stage,generative-upscale,keyframes}, get_memory for the device

[dkackman]

Siblings from the same research pass: #152 (Deblur/Decompression restoration), #153 (diffusion VAE decode). Deliberately not filed: DFR adoption (upstream's production path, but it lives in ltx_pipelines not diffusers — a second runtime, so a design call for Don) and NVFP4/FP8 (ruled out: lem is an RTX 3090, NVFP4 needs Blackwell SM>=10, and SDNQ uint4 is already more aggressive).

[dkackman]

Blocked on something only a human can clear, so this is parked with Don rather than handed to the tester. Worked as model opus via provider anthropic.

The gate on the new IC-LoRA repos has not been accepted by the account lem authenticates as. Your write-up flagged them as gated: auto and noted lem "clearly already has access (it pulls the upscaler fine)". That inference does not hold — the gates are per repo, and this batch was never accepted. Checked from lem with its own token:

LTX-2.5-22b-IC-LoRA-Pixel-Spatial-Upscaler  README  OK      file range request  OK
LTX-2.5-Diffusers                           README  OK      (model_index.json read fine)
LTX-2.5-22b-IC-LoRA-Ingredients             README  403     file range request  403
LTX-2.5-22b-IC-LoRA-Deblur                  README  403
LTX-2.5-22b-IC-LoRA-Decompression           README  403

The public model metadata API answers for all of them, which is why the file list, versions and dates in your write-up were readable. Files and cards are not.

What that blocks, concretely. Two things, and the second matters more than the first:

1. The weights cannot be downloaded, so a template would 403 at run time — for the tester too, not just for me.
2. The conditioning format is unverifiable. You flagged this yourself. generative-upscale drives LTX2ReferenceCondition with a single reference at reference_downscale_factor: 2, and Ingredients is multi-reference identity conditioning — how many reference_conditions entries, at what strength, at what downscale factor, and whether the prompt needs a particular form are all things the card would tell us. Writing a template from the upscaler's shape and hoping would produce something that validates and generates the wrong thing, which is the failure mode hardest to notice.

So the honest position is that this is an hour's work sitting behind one click, and guessing at it is worse than waiting.

What unblocks it: visit https://huggingface.co/Lightricks/LTX-2.5-22b-IC-LoRA-Ingredients while signed in as the account whose token is in ~/.cache/huggingface/token on lem, and accept the licence. Same for Deblur and Decompression (#152). Then hand this back with owner:implementer and no status label.

What I did confirm in the meantime, so none of it needs redoing:

• The plumbing claim is right: LTX2InContextPipeline + reference_conditions + a loras entry is all these need, and generative-upscale is the working shape to copy. No engine work.
• The upscaler pin is current, as you said — that repo still holds exactly the one x2-1.0 file dw names. No action, as you recommended.
• Everything on the LTX side that was not gated, I did ship: templates/ltx2/diffusion-decode for Untested: the LTX-2.5 family decodes with the conv VAE and never uses LTX2VideoDiffusionDecodePipeline #153.

Routing note: the role's rule for a blocked issue is status:needs-info with owner:tester, but the tester talks only to the MCP server and cannot accept a Hugging Face licence. Parking it with you instead, since you are the only one who can move it.