Nodes/Kinburg-Nodes/Lora Unlim Accumulator
ComfyUI Node

Lora Unlim Accumulator

Stack 10 LoRAs and Keep Their Trigger Words in the Prompt

By Kinburg·Created 3 months ago·Updated 6 days ago· 1
Lora Unlim Accumulator
  • model
  • clip
  • lora_1
  • lora_2
  • model
  • clip
  • prompt
  • triggers
prompt

Core ComfyUI stacks LoRAs as a chain of loader nodes - five LoRAs, five nodes in a row, each with its own chance for a wrong strength or a wrong order, and the trigger words all typed by hand into the prompt where they get lost on the next revision. Lora Unlim Accumulator is the node that fixes both halves at once: it applies any number of LoRAs onto your model and appends their trigger words to the prompt, in the same run. It's the output half of the pack's LoRA stack, and the input half is the LoraTriggerLoader spec nodes.

How it works

You feed it:

  • model (required) - the base diffusion model.
  • clip (optional) - connect it and each LoRA's strength_clip is applied to CLIP too; leave it empty and it's model-only. The clip input sits above the first LoRA slot.
  • prompt (optional, input-only) - wire your text prompt in.
  • lora_1, lora_2, … - the auto-growing list of KINBURG_LORA specs from LoraTriggerLoader. Connect the last slot and a new empty one appears; the node shows only the connected slots plus a spare.

It loads and applies each LoRA in slot order, appends the non-empty trigger words to the prompt in their own paragraph after a blank line (comma-separated among themselves), and outputs the patched model / clip / prompt - plus a triggers output that's just the comma-separated trigger words, no prompt.

What the triggers output is for

This is the detail that shows the pack was built by someone actually running LoRA-plus-LLM workflows. If an LLM rewrites your prompt, it will cheerfully drop your LoRA triggers - the model doesn't know "ch9ractername" is load-bearing. triggers exists to be wired into a node like the pack's Ouroboros sampler's trigger_words input, so the triggers survive an LLM prompt rewrite. That's a genuinely thoughtful bit of plumbing.

A LoRA with no effective strength (off) is skipped entirely - neither applied nor added to the prompt - which means you can keep a LoRA loaded in the chain but muted without it polluting your prompt. Loaded files are cached per run. The stacking order is slot order, so put your strongest LoRA last if you want it most dominant, and keep in mind LoRAs are architecture-bound - an SDXL LoRA does nothing on Flux, so stack within a family.

Install

Part of the Kinburg-Nodes pack - ComfyUI Manager (search "Kinburg-Nodes"), or cd ComfyUI/custom_nodes && git clone https://github.com/Kinburg/Kinburg-Nodes, restart. No extra dependencies. The work is standard ComfyUI LoRA loading under the hood, so no models to fetch - just your existing LoRA files. If you stack more than two LoRAs, this is the node that makes it feel like one operation instead of a chain of mistakes.

CategoryKinburg-Nodes/lora

Inputs (5)

NameTypeDefaultDescription
modelMODELBase diffusion model the LoRAs are applied to.
clipoptCLIPOptional CLIP. Connected -> LoRAs are applied to it too (with each LoRA's strength_clip) and returned; left empty -> model-only.
promptoptSTRINGText prompt (input only). The LoRAs' trigger words are appended to it, in slot order.
lora_1optKINBURG_LORA
lora_2optKINBURG_LORA

Outputs (4)

NameTypeDescription
modelMODEL
clipCLIP
promptSTRING
triggersSTRING