Shima Lora Stack
Three more LoRA slots, or a chain you can keep stacking
- lora_stack
- LORA_STACK
Shima Lora Stack is the extension node for Model Citizen: it gives you three more LoRA slots and hands you a LORA_STACK you can feed into the loader (or chain into another Lora Stack). If Model Citizen is the base loader with three slots, this is how you get to six, nine, or more without touching Model Citizen's own widgets.
The mechanism is a standard stack pattern. Each slot is a (name, strength) pair, the node filters out the "None" and zero-strength entries so dead slots don't pollute the stack, and - the nice touch - it prepends any incoming lora_stack before its own three. That ordering matters: the lora_stack input exists precisely so you can chain stacks, and prepending means the upstream stack applies first, in the order you built it. Feed one Lora Stack into another and you get a deterministic, ordered list of LoRA configs that Model Citizen applies in sequence.
What to set
- lora_1_name / lora_2_name / lora_3_name - the three dropdowns, populated from your
lorasfolder. - lora_1_strength / lora_2_strength / lora_3_strength - per-slot strengths, −10 to 10. Most LoRAs live around 0.6–1.0; negative strengths are technically allowed and occasionally used for style removal, but keep them out of your everyday builds.
- filter_by_model_type - a convenience dropdown (All/SDXL/SD1.5/SD3/Flux/SD2.1) that trims which LoRAs appear in the lists. It doesn't enforce compatibility, just declutters.
- lora_stack - the chainable input: wire another Lora Stack's output here to append that stack's configs before this node's own.
The single output is LORA_STACK, ready for Model Citizen's lora_stack input. It's a pure data node - no model loading happens here; the LoRAs are applied downstream when the stack is consumed.
Install
Standard pack install:
cd ComfyUI/custom_nodes
git clone https://github.com/KDB-USJP/shima_wf
then restart, or ComfyUI Manager → search "Shima". No models or extra pip packages.
The honest take
This node only makes sense inside the Shima loader family - its LORA_STACK type is consumed by Model Citizen and friends, so you won't wire it into a stock LoraLoader. Within that ecosystem it's exactly the right shape: order-aware, chainable, and it silently ignores empty slots, which is the kind of forgiving behavior that keeps a big stack from exploding. The one thing that will surprise you is ordering - because incoming stacks are prepended, adding a Lora Stack node to a chain changes which LoRA applies first, and with LoRAs that fight each other, order is the difference between a style and a mess. If a chained stack behaves differently than the sum of its parts, that's the first thing to check. For anyone running many LoRAs on one checkpoint, it beats hand-building stack lists, and it keeps Model Citizen's own three slots free for the LoRAs you actually want to see on the node face.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| filter_by_model_type | COMBO | All | 6 options: All, SDXL, SD1.5, SD3, Flux, SD2.1 |
| lora_1_name | COMBO | None | 1 options: None |
| lora_1_strength | FLOAT | 1.00-10–10 | — |
| lora_2_name | COMBO | None | 1 options: None |
| lora_2_strength | FLOAT | 1.00-10–10 | — |
| lora_3_name | COMBO | None | 1 options: None |
| lora_3_strength | FLOAT | 1.00-10–10 | — |
| lora_stackopt | LORA_STACK | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| LORA_STACK | LORA_STACK | — |