Use Loaded Model

If you run multi-pass workflows - a base pass, a detailer pass, a second sample - you've watched the same model file get loaded over and over, burning seconds and VRAM churn every time. Use Loaded Model is this pack's answer: the half of a Load New Model / Use Loaded Model pair that reuses an already-loaded runtime instead of reloading it.

The pairing is the point. Load New Model receives a model selection (from the pack's Checkpoint Selector, Diffusion Model Selector, etc.) and does the heavy lifting of loading the actual runtime - with a strong cache so the same prompt doesn't double-load. Use Loaded Model sits where your graph actually consumes the model and keeps the final runtime in a process-local cache, keyed by the selection, runtime settings, LoRA stack, and connected clip/vae. On a cache hit, the whole load branch is skipped and you get the model, clip, and VAE back instantly.

What goes in

• model (required) - the IPT-Model selector value. This is the primary key for reuse; it's what determines whether the runtime gets reloaded.
• apply_lora_stack (default true) - whether the node applies lora_stack internally. If your loaded_model / loaded_clip inputs already have the LoRAs applied upstream, set this false.
• lora_stack (optional) - the LoRA stack to apply (and a cache key component).
• clip, vae (optional) - references used as part of the cache key for diffusion-model setups.
• loaded_model, loaded_clip, loaded_vae (optional) - the raw/patched runtimes for the cache-miss path. When the cache hits, this whole branch is lazy-skipped.

Outputs: model, clip, vae - the ready-to-use runtimes.

The LoRA gotcha that bites everyone

The node applies lora_stack internally by default, and the stack is part of the cache key - order- and strength-sensitive, so swapping two LoRAs or changing a strength counts as a different condition set (correctly, since the result would differ). The trap: if your loaded_model/loaded_clip already have the same LoRAs applied upstream and you leave apply_lora_stack on, you get double-applied LoRAs. The README is explicit - set it false in that case. Similarly, if you want pass-through nodes like a LoRA loader or TorchCompile between the load and the use, they go after Load New Model, and their outputs feed the loaded_* inputs with apply_lora_stack=false.

Tuning the cache

Behavior is configurable under ComfyUI Settings → Info-Prompt-Toolkit → Use Loaded Model Cache. Auto keeps the latest entry and prunes older ones by estimated memory against a Memory budget ratio; Fixed keeps up to Max cache entries (default 1, 1–9) regardless of budget. There's also a Use cache logging toggle that prints hit/miss/store/evict messages with estimated memory to the Python console - genuinely useful when you're trying to figure out why a pass reloaded when you expected a hit.

Install

Standard pack install:

cd ComfyUI/custom_nodes
git clone https://github.com/kinorax/comfyui-info-prompt-toolkit.git
cd comfyui-info-prompt-toolkit
pip install -r requirements.txt

Or ComfyUI Manager → search "ComfyUI-Info-Prompt-Toolkit" → install → restart. No extra models needed.

Where people get burned

Beyond the LoRA double-apply, the cache is the other classic gotcha: it keeps runtime in memory by design, so the more entries you allow, the more VRAM it holds onto. Max cache entries: 1 is the sensible default for a single-model workflow. If you're switching models constantly and hitting OOM, your first move is shrinking the cache (or clearing it) - the pack's Release Memory node exists for exactly this cleanup. And remember the cache is per-process: restart ComfyUI and it starts cold, which is normal, not a bug.