AIO Load Pipeline Models

The whole point of AIO Image Generate is that you don't build a pipeline. But occasionally you have to - you want to run an attention patch, a model-scale tweak, or a custom LoRA chain that the one-node facade can't express. AIOLoadPipelineModels is the pack's escape hatch: it loads the same diffusion model and text encoder the main node would load, applies your AIO LoRA stack, and hands you standard ComfyUI MODEL and CLIP values to run through any external patch node. Then you feed the patched results back into the main node's model and clip inputs, and generation continues as if nothing happened.

How it works

Inputs: model_type (same four families), diffusion_model, and text_encoder - the same filename dropdowns as the main node. Two optional inputs: model_settings (an AIO_MODEL_SETTINGS from the matching settings node, used for precision policy and performance patches) and lora_config (an AIO_LORA_CONFIG from AIO LoRA Configuration, applied before the models are output).

Outputs: model and clip, plain ComfyUI MODEL/CLIP.

The mechanism matters: when both model and clip are connected to AIO Image Generate, the main node treats them as already post-LoRA and skips its internal model/CLIP loading and LoRA application. So the handoff is explicit - the loader outputs are the post-LoRA models, you patch them, and the main node picks up where you left off. If your patch only modifies MODEL, you can route the loader's clip output straight into the main node's clip input and only the model side goes through the patch nodes. The main node doesn't guess; if you only connect model and leave clip empty, that's a different (and probably wrong) configuration.

When to use it

• You're running a model-scale or attention patch that has to land after LoRAs but before sampling.
• You want a LoRA chain (AIO's ordered rows followed by an external loader) that the single lora_config socket can't represent.
• You're testing an experimental patcher against the pack's exact model loading without rebuilding the pipeline by hand.

For everything else - plain generation, references, inpaint - you don't need this node at all, and adding it is pure overhead. It exists for the 10% of workflows that need to reach past the facade.

Install and wiring

Part of the AIO 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; it's under AIO/Image. The typical graph: AIOLoadPipelineModels → your patch node(s) → model/clip on AIO Image Generate. Keep the model_type and model files consistent between the loader and the main node, or you'll be sampling with a different model than the one you patched.

Gotchas

• Both sockets, or a deliberate one. The "skip internal loading" contract only triggers when both model and clip are connected (or you consciously route the loader's clip across for a model-only patch). Connecting just model and expecting the pack to fill in clip from elsewhere is a footgun.
• LoRAs apply once. The loader applies the lora_config before output. If you also leave a lora_config on the main node, you're double-applying. The main node expects post-LoRA models on these sockets.
• Settings still need to match. Feed it a model_settings from the wrong family and validation will complain.

It's the node you'll never open in a simple workflow and can't live without in a complicated one - the classic escape hatch, and a well-designed one.