🧰 Universal Conditioning IO (Save/Load/Pass)

The ConditioningIO node saves your prompt, encoded, to a .bin file on disk - and loads it back later. Why would you ever want that? Because the text encoder is quietly the biggest single chunk of VRAM in a modern workflow, and it's the one you use for about two seconds at the start of a generation. The 2026-model reality is that the "text encoder budget" is now a separate line item: Flux-class T5s, Qwen encoders, and multi-GB UMT5 stacks hog several gigabytes all by themselves. On a 16GB card, that's the difference between fitting your sampler and watching it OOM.

The name is honestly not a lie: this is the classic "encode once, use forever" trick, as a node. You run Stage A (text encode → save), unload the text encoder entirely, then run Stage B with just the diffusion model and VAE loaded. Load a saved conditioning and you never touch the text encoder again. That's the whole point of this pack, and it's the one reason worth reaching for it.

How it works

It's a three-mode node, and mode is the only required input. pass (the default) just passes your conditioning straight through - no save, no error. That makes it safe to drop into any workflow as plumbing without changing behavior. save writes the conditioning tensor to ComfyUI/models/conditionings/ as a .bin (plain torch.save, CPU-serialized by default so it's portable), and still passes the data through on its conditioning_out. load reads a .bin back and hands you a conditioning you can wire straight into a KSampler's positive or negative socket.

The useful details:

• save_path - a fixed name gives you overwrite-style saving: same name, file replaced, no unbounded numbering. Leave it empty and you get auto-numbered files (Conditioning_00001_.bin).
• auto_delete - temp-file mode. Deletes the old file before each save, so the disk only ever keeps the latest. This is the one-two punch for a repeatable two-stage workflow: fixed save_path + auto_delete and Stage A is idempotent.
• device - cpu (default) is the portable choice; auto follows wherever the data currently lives; gpu forces a VRAM backend (XPU→CUDA, falling back to CPU with a warning). Load always migrates to whatever device you pick, so files saved on any box load anywhere.

Outputs: conditioning_out (CONDITIONING) and filename (STRING, the file that was written or loaded - handy if you want to log it or feed it somewhere). It's an OUTPUT_NODE, so a save-only graph passes ComfyUI's "no outputs" validation without you tacking on a dummy preview node.

Where people get burned

• The conditioning_file dropdown can't take a STRING link from another node. It's a ComfyUI COMBO limitation - pick the file by hand in the GUI. Annoying, not a bug.
• Save with identical inputs may be skipped because ComfyUI caches nodes that didn't change. Tweak any parameter to force a rerun.
• The "conditioning" isn't magic text. It's the token + pooled embeddings your CLIP/T5 produced, so a conditioning saved from one text encoder loads into a sampler fine as long as the model is the one it was encoded for. Don't mix a Flux conditioning into a Stable Diffusion sampler.

The whole pack is a refactor of the older ComfyUI-SaveLoadUniversalConditioningLatent (4 nodes → 2), and it fixed some real bugs on the way: files used to land outside the ComfyUI directory, the VRAM-clearing call was a no-op on Intel Arc, and the save routine mutated class instances in place, corrupting ComfyUI's cached outputs. This version uses the official folder_paths API and shallow-copies data instead of mutating it.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/hqh330/ComfyUI-UniversalIO.git

Then restart ComfyUI. You can also grab it from ComfyUI Manager by searching "UniversalIO" (or "Conditioning" / "IO"). No model downloads, no Python dependencies beyond what ComfyUI already ships - it's pure torch plumbing.

The one workflow worth stealing

If your card can't hold TE + UNET + VAE at once (the README's example: H3 at ~9.5GB TE + 9.1GB UNET + 5GB VAE > 16GB VRAM), split it: encode and save in Stage A, then run Stage B with only the UNET and VAE. Because .bin files are pure CPU-serialized data, you can even upload one to a cloud box and run Stage B on a rented big GPU. One node, half the VRAM, same prompt - that's the deal.