TS Load LoRA, model only

What it is

The third of Timesaver's three locked-model nodes, and the one that gives away what the other two are for. It applies a .tsmodel LoRA to a model and returns the model - LoraLoaderModelOnly, for a locked file.

The "model only" part is not laziness. The models these locks get used for are video models and distilled checkpoints: LTX, Wan, Krea 2. Those graphs have no CLIP wire in them at all. A model-and-CLIP loader would hand you two outputs where you have exactly one place to plug in, and the CLIP half would sit there unconnected forever. The pack had the paired version for a single day and pulled it at the owner's request, which tells you how much anyone missed it.

How it works, and the two decisions in it

The node opens the .tsmodel, hands it to comfy.sd.load_lora_for_models, and merges it into the model you gave it. (It passes the LoRA metadata through, with a fallback for older ComfyUI builds that don't accept that argument - a small thing, but it's why the node keeps working across versions.)

The decision worth knowing about is at strength_model = 0. Zero does not mean "apply zero"; it means return the model untouched. The stock node behaves this way and graphs depend on it - it's how you keep six LoRAs wired up and switch one off by dragging its weight to 0 instead of rewiring the graph at 2 a.m. Same for the negative side of the range: negative strength subtracts the adapter's effect, which is occasionally exactly what you want and usually an accident.

About the .tsmodel format itself: it's a safetensors file whose 8-byte header length is replaced with a magic marker and whose JSON header is zlib-compressed, with the tensor data untouched in place. Anything other than this pack's loaders just fails on it. There's no password and no cryptography - it keeps a file from being casually grabbed and loaded, and that's all it claims to do.

Inputs and outputs

model - whatever the LoRA goes on, typically out of TS Load Diffusion Model or TS Load Checkpoint.

lora_name - a dropdown of .tsmodel files from models/loras, subfolders and extra_model_paths.yaml folders included. Empty list means the folder is empty, not that the node is broken.

strength_model - default 1.0, range −100 to 100, 0.01 steps. LoRA weights are architecture knowledge, not taste: the old 0.5–0.8 rule of thumb is SDXL folklore, and on the 2026 architectures people routinely run 1.0 and above because dropping the weight visibly costs likeness. Start at 1.0 and move from there.

One output: model, into the sampler. Stack a second node if you need a second adapter - the node takes one LoRA at a time.

Install

ComfyUI Manager → search Timesaver, or:

cd ComfyUI/custom_nodes
git clone https://github.com/AlexYez/comfyui-timesaver
cd comfyui-timesaver
python -m pip install -r requirements.txt

Restart ComfyUI. No model downloads and no optional extras for this node; the reader is part of the pack. Windows portable users: run pip from python_embeded\python.exe, or the install lands in a different interpreter than ComfyUI's.

When the LoRA "does nothing"

Walk it in this order. First, is strength_model actually 0? Zero is a deliberate bypass, not a broken merge, and it survives workflow saves. Second, is the sampler holding the pre-LoRA model? The node returns a patched clone; if you re-wire the original out of habit, the LoRA is on a branch that nobody reads. Third - the one the node can't catch - is the LoRA the right architecture? Adapters are architecture-bound: an SDXL LoRA does nothing on a video model, and locking says nothing about what's inside the file. There is no fingerprint check here; a .tsmodel LoRA for the wrong family will merge into whatever keys happen to match and leave you wondering.

Wrong folder is the loud version of that problem, and it fails properly: point lora_name at something ComfyUI can't find and the node names the models/loras folders it searched.