AIO LoRA Configuration

If you've used rgthree's Power LoRA Loader, you already know this node's UI. AIOLoraConfiguration is the AIO pack's LoRA stack: add ordered rows, toggle rows on and off, reorder or remove from the row context menu, toggle all from the node menu, and pick single or separate model/CLIP strengths. The README credits rgthree-comfy directly - this is an adaptation, not a coincidence. What makes it worth using instead of dropping rgthree alongside is the output: one AIO_LORA_CONFIG dict that goes straight into AIO Image Generate's lora_config socket, where the main node applies it at the right point in its pipeline (after model/text-encoder load, before prompt encoding and sampling - the same placement a hand-built workflow would use).

What you actually set

The node is deliberately widget-light because the real UI lives in the rows:

• show_strengths - single (one shared strength per row) or separate (independent model and CLIP strengths per row).
• match - an optional regex that filters the LoRA chooser list, so you can narrow a 400-file loras folder to "style" or "character" without scrolling.

Then the dynamic rows: each row holds a LoRA name, an on/off toggle, and strength(s). The backend uses ComfyUI's LoraLoader.load_lora, so files stay lazy - nothing loads at import time, and only enabled, non-zero-strength rows are applied and reported in run_info.loras.

Two things that make it more than a reskin

The LoRA info dialog is local. The info button reads the selected LoRA's metadata and any existing sidecar without a Civitai API call - no network round-trip, no disk write just for looking. Civitai data is fetched only on an explicit refresh action, keyed by SHA256, and persisted to a *.aio-lora-info.json sidecar next to the LoRA with your notes and strength hints. All file access is confined to ComfyUI's configured LoRA roots.

API workflows get a control channel. An API-only stsc_lora_control input (invisible in the UI) accepts a JSON object or an stsc-lora-v1: base64url payload that can replace or merge the LoRA stack per request - so a frontend can swap LoRAs without touching the serialized workflow. Malformed payloads, ambiguous names, duplicate entries, and stacks over 64 rows fail before application rather than silently mis-applying.

Family-specific behavior

The LoRAs land on the diffusion model (and CLIP where a family has one). The notable exception: Ideogram 4 applies LoRAs to the conditional diffusion model only, matching ComfyUI's LoraLoaderModelOnly pattern - its Qwen3-VL text encoder and unconditional model are never LoRA-patched. And when run_unconditional_model is off in AIOIdeogram4Settings, the unconditional model isn't loaded at all, so a LoRA that tried to patch it has nothing to patch. Keep that in mind if you're stacking Ideogram LoRAs.

Install and wiring

Ships with the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/helto4real/comfyui-all-on-one-image-generation-node
cd comfyui-all-on-one-image-generation-node
python -m pip install -r requirements.txt

Or ComfyUI Manager → search "AIO Image Generate" → install → restart. Connect lora_config to the main node, and optionally also feed the same AIO_LORA_CONFIG to AIO Load Pipeline Models if you're doing external patching.

Gotchas

• match is a regex, not a search box. flux filters for "flux"; flux|style unions. If the list suddenly looks empty, you've written a regex that matches nothing.
• Ideogram's model-only application is by design. Don't expect your LoRA's CLIP side to land on a Qwen3-VL encoder.
• Double-apply risk. If you use AIO Load Pipeline Models with a lora_config and leave one on the main node, you're stacking. Pick one home for the LoRA stack.

It's the most "borrowed-but-improved" node in the pack - familiar UI, pack-native contract, and a local info path that doesn't phone home.