LoRA Switcher (Dynamic)
One Node, Every LoRA, Pick By Number
- model
- clip
- MODEL
- CLIP
LoRA Switcher (Dynamic) is the node you build when you're sick of dragging LoRA loaders around the canvas. Instead of a fixed layout of LoRA Loader nodes - the classic five-LoRA grid, then the twenty-LoRA grid when that's not enough - this one holds an arbitrary list of LoRAs in a single node and applies whichever one you point at. It's data-driven LoRA selection: same graph, different result, every run.
The distinction matters, so let's be honest about it. If your job is stacking five LoRAs together with per-LoRA toggles and trigger words, the community standard is rgthree's Power Lora Loader, and it's hard to beat there. This node isn't that. It's for the case where you want to switch which single LoRA is active based on an index - the exact pattern you want for batch runs, A/B testing, or a workflow driven by an external process (an API caller, a frontend form) that changes the selection between generations without you editing the graph.
How it works
This is the one node in the pack with real moving parts. A bundled frontend script adds an editable table to the node - rows of LoRA name plus strength, and it grabs your actual LoRA list from ComfyUI through a custom endpoint the pack registers (/oshtz-nodes/get-loras). Every time you change a row, the frontend serializes the whole table to JSON and hands it to the backend through a hidden lora_config input.
On the Python side, the node parses that JSON, pulls out the row at active_index, and applies it by calling ComfyUI's own built-in LoRA loader:
model_lora, clip_lora = LoraLoader().load_lora(
model, clip, lora_name, strength_model, strength_clip
)
No new inference engine, no reinventing loading - it wraps the same LoraLoader you'd use by hand, which also means the LoRA compatibility rules apply exactly as normal: an Illustrious LoRA on a Flux checkpoint still fails the same way it always does.
The inputs and outputs that matter
- model (MODEL) and clip (CLIP) - the standard checkpoint outputs feeding in, just like any LoRA loader.
- active_index (INT, default 0) - which row to apply. Here's the gotcha: it's 1-based. Index 1 applies the first row, 2 the second, and so on. Zero (or any out-of-range value) means no LoRA - the node passes your model and CLIP through untouched.
Outputs are MODEL and CLIP, ready to feed your sampler. Missing LoRA file or a bad row? It logs a console warning and passes through unchanged rather than crashing the run - friendly, but it means a wrong index can silently give you a "no LoRA" result, so keep an eye on that number.
Installing it
Part of the oshtz Nodes pack, installed as one unit. ComfyUI Manager: search "oshtz". Or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/oshtz/ComfyUI-oshtz-nodes.git
cd ComfyUI-oshtz-nodes
pip install -r requirements.txt
Restart ComfyUI after. Dependencies are just requests, pydantic, Pillow, and numpy - the LoRA loading itself is done by ComfyUI, so there are no extra model files to fetch.
When you'd actually reach for it
The sweet spot is scripted or batch use: you want to generate the same scene with twenty different character LoRAs and compare, or an API workflow needs to select a LoRA by number on each request. Point active_index at a varying value, and one node does the switching. If you're just setting up a static "these three LoRAs for this style" workflow, a plain loader (or Power Lora Loader) is simpler - but for switching by number, this is the one.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| clip | CLIP | — | |
| active_index | INT | 0 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |