H3 LoRA Tags (from the graph, for Image Saver)

What it is

One input, two strings out. lora_tags gives you the LoRA chain applied to the MODEL you wired in, written as <lora:name:strength> tags in the order they're applied; model_name gives you the base model's filename without its extension. You feed both into the metadata node of Image Saver (Image Saver Metadata) so the file you upload to Civitai carries the right resources instead of whatever you remembered to type.

If you've never typed resource tags by hand, this sounds like a solution looking for a problem. Then you swap the 4-step Turbo LoRA for the 8-step one, add the StyleTransfer LoRA for a guide-mode render, and the tags in your metadata quietly describe a workflow that was true two hours ago. LongTake makes this easy to get wrong: up to four LoRAs in play, an hour-long render, and you find out on the upload page.

How it works, and why it's free

The clever bit is what the node does not do. Its model input is lazy: the class declares check_lazy_status returning an empty list, so the engine never evaluates the upstream MODEL at all. No checkpoint is loaded, no LoRA is merged, no VRAM is spent. The node only needs the wire to exist so it can follow it, which the author says in the tooltip - "It is not loaded: it only serves to find the chain in the graph."

What it reads instead is the queued prompt itself, through the hidden PROMPT and UNIQUE_ID inputs every node can ask for. Starting at whatever node feeds model, it walks upstream link by link and collects, at each step:

• any widget named lora_name, together with its strength_model or strength;
• rgthree's Power Lora Loader entries, which arrive as dicts of {on, lora, strength} - switched-off rows are ignored;
• unet_name or ckpt_name, which is where model_name comes from.

Filenames get stripped to basenames without the extension, strengths go through %g formatting, and anything whose strength is zero is dropped, which is the honest answer - a LoRA at zero strength isn't applied. Because each newly found LoRA is prepended, the string ends up in application order, loader-most first.

Two consequences follow, and both are the reason I'd wire it rather than type it. First, it sees exactly one branch: the model link you connected. A LoRA sitting on some other branch of the graph isn't in the chain and doesn't appear, which is correct, but it does mean the answer changes if you re-route. Second, it can only see LoRAs that are expressed as widgets on that walk - a loader-style node with a lora_name field, or rgthree's Power Lora Loader. If a pack applies LoRAs internally with no widget to read, this node can't know, and lora_tags comes back empty rather than wrong. No error, no warning. Look at the string.

Wiring it

lora_tags → the metadata node's LoRA/prompt field on Image Saver (the pack README points at Image Saver Metadata), and model_name → its base model field. That's the whole graph. The node isn't an output node, so it doesn't run on its own - it executes because something downstream pulls from it, which in practice means you wire it into the metadata branch and that branch saves a file.

For a LongTake graph the natural tap point is the MODEL that goes into the Render, after all the LoRA loaders, so the chain is the rendered one rather than the intended one. If you're tagging a video rather than a still, pair it with H3 Video File, which turns the Stitch's mp4 path into something Image Saver's video metadata node will accept.

Install

It ships in the same pack as the rest of LongTake. ComfyUI Manager → search H3 LongTake → Install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/mark9009/ComfyUI-H3-LongTake

Restart ComfyUI and both nodes appear under the H3 LongTake category. No extra Python packages - the pack's pyproject.toml declares no dependencies and there's no requirements.txt, because all this node touches is the prompt dictionary it was already handed. It's in the Comfy registry too, so Manager will show updates.

Gotchas

Empty output = the walk didn't recognise your loader. Most common with a loader whose widget isn't called lora_name and isn't rgthree's dict. Nothing breaks; you just get a blank tag string and a metadata file that claims the render used no LoRAs.

It only knows the current prompt. Values come from the graph as queued, not from what's in the file on disk. Re-queue after changing a strength if you want the tag to match.

model_name is a filename, not a friendly name. It's the basename of your unet_name/ckpt_name with the extension removed, e.g. minimax_h3_ref2va_pruned_fp8_scaled. Handy for Civitai, which wants a resource name it can look up; just don't expect it to say "MiniMax H3".

Don't wire the pre-LoRA model and expect the tags. If you tap the MODEL straight off the loader, you get an empty chain. The tooltip says it: the MODEL that goes to the Render, after the LoRAs.