LoadLoraFromLoraList

Chain six LoRA loaders in a row and your graph turns into a staircase of identical nodes you have to re-wire every time you change your mind about order. LoadLoraFromLoraList collapses that into one node: hand it a MODEL and a multiline string full of <lora:name:strength> tags, and it applies them all in order and gives you the model back.

This is the loading half of the pack's prompt-file idea. PromptDecode parses a TOML prompt and emits a list of LoRA tags it found in the text; MultipleLoraTagLoader builds such a list by hand; either output plugs straight into this node's lora_tag_list.

How it works

The node splits the input on newlines and tries each line against a regex for the standard tag form:

<lora:my_style.safetensors:0.7>
<lora:my_style.safetensors:0.7:0.7>

Each match goes through core LoraLoaderModelOnly in sequence, so order is preserved and later LoRAs stack on the result of earlier ones. Two details from the source are worth knowing:

• Duplicate names are skipped. If the same LoRA filename appears twice, only the first wins - the node keeps a set of names it's already loaded.
• Non-matching lines are ignored. Anything that isn't a well-formed tag is silently skipped rather than erroring, which is what makes it safe to feed a line-oriented list that also contains comments or prompt text.

One asymmetry to plan for: MultipartCLIPTextEncode in the same pack stops at a -- line, but this node does not. If you feed it the raw lora list that PromptDecode produced - which uses -- to separate high-noise from low-noise LoRAs - it will happily load both groups. For a Wan 2.2 high/low expert setup that's exactly wrong; run the list through SplitLoraList first and give each half to its own LoadLoraFromLoraList.

Also note this is the model-only loader. It changes the MODEL weights, not the text encoder - appropriate for most modern LoRAs, but if a LoRA was trained with text-encoder side effects and needs them, you want the CLIP-aware path (MultipartCLIPTextEncode loads via LoraLoader, which does both).

Inputs and outputs

model - "The diffusion model." lora_tag_list - a multiline STRING, "LoRA tag list." One MODEL output. No CLIP or VAE outputs, because it doesn't touch them.

Install

Manager search for the pack, or:

cd ComfyUI/custom_nodes
git clone https://github.com/morino-kumasan/comfyui-toml-prompt

restart ComfyUI. Nothing to pip install - the repo's requirements.txt is empty, and the LoRA machinery comes from ComfyUI's own LoraLoaderModelOnly. The README's install block is stale on both the repo name and the clone URL.

Where people get burned

A tag that doesn't match the regex is skipped without a word. The pattern only accepts a numeric strength - [-0-9.]+ - so <lora:name:0.7 > with a trailing space, or a misspelled <Lora:...> with a capital L, loads nothing and tells you nothing. If a LoRA appears to have no effect, print the tag list and compare it to the pattern.

A wrong filename errors from inside ComfyUI's lora folder lookup, which reads as a generic "file not found" against models/loras. Subfolders use forward slashes in the tag, and the node normalises separators for you.

Strength is per-tag, not global. There's no master scale on this node - if you want to run everything at 0.8, that goes in the tags themselves (MultipleLoraTagLoader is the friendlier way to set them, with a strength widget per slot).