Set Lora Stack Extra

Set Lora Stack Extra writes a LoRA stack into the pack's metadata extras. Of all the Set nodes, this is the one with the most to actually serialize: a LoRA stack isn't a number or a string - it's a list of LoRA references, each with a name and a strength, and this node packs the whole thing under a key so it can ride in the image's infotext.

Why is that valuable? Because a LoRA stack is precisely the thing that's easy to lose and painful to reconstruct. The metadata round-trip that this pack builds its identity on natively captures the model and sampler - but a multi-LoRA stack applied at specific strengths is a configuration, and if it isn't persisted, reloading an image means guessing which LoRAs you used and at what strengths. Store the stack once and the recipe comes back with the file, faithful to the last decimal.

Inputs and outputs

• key - the parameter line key for the serialized stack.
• lora_stack (optional) - the IPT-LoraStack to store. This is the interesting part: leave it disconnected and the node just adds an empty entry; connect it and the whole stack (names and strengths, in order) gets serialized. In a real workflow this comes from a Lora Selector, a prompt-to-stack node, or Image Info Context's lora extraction.
• extras (optional) - the incoming extras bundle to merge into.

Output is the merged extras bundle.

The stack is stored as a single metadata line, and the matching Get Lora Stack Extra node parses it back into a typed IPT-LoraStack on load - order preserved, strengths preserved. That round-trip fidelity is the whole point: a LoRA stack is ordered and strength-sensitive, and sloppy persistence (alphabetize the names, round the strengths) would silently change what the image means.

Why order and strength matter

If you've tuned multiple LoRAs you know the order isn't cosmetic. A style LoRA and a character LoRA applied in different orders, or with a 0.6 instead of 0.8, produce different images. This node stores the stack exactly as given - no dedup, no reordering, no strength normalization. So the saved metadata is a true record of the composition that produced the image, which is exactly what you want when you reload it and expect the same output. (If you're the type who saves an image and later wants a cleaned recipe - the pack's caption/preprocessing nodes handle that side; this node's job is faithful storage.)

Install

Standard pack install:

cd ComfyUI/custom_nodes
git clone https://github.com/kinorax/comfyui-info-prompt-toolkit.git
cd comfyui-info-prompt-toolkit
pip install -r requirements.txt

Or ComfyUI Manager → search "ComfyUI-Info-Prompt-Toolkit" → install → restart. No models, no extra dependencies.

Where people get burned

The usual extras rules still apply - a pack saver must write the file, duplicate keys overwrite - plus one LoRA-specific trap: the stored stack is only as good as the stack you fed it. If your lora_stack socket is fed by a node that applies LoRAs with different effective strengths than what's in the stack, the metadata records the stack's values, not the applied values. Keep the stack and the application path in sync, or your "faithful record" is quietly a lie.