Save TE conds Pre-computed as Safetensors file

Every time you hit Queue on a Flux or SD3.5 workflow, T5-XXL re-reads your entire prompt. Every time you queue a Wan video with a prompt you haven't changed, UMT5-XXL does the same. For a fixed prompt across a seed sweep or a LoRA test, that's a lot of wasted compute - the encoding is identical every run. SaveCondsEmb is the pack's answer: take a CONDITIONING that's already been encoded, flatten it, and write it to a safetensors file you can load back later with LoadTEConds (or splice into a live conditioning with InsertTEConds). Encode once, pay once, replay forever.

It's a deliberately boring node, and that's the point. You wire it onto the output of your CLIP Text Encode, tell it which encoder the conditioning came from, give it a filename, and it dumps the token tensor to ComfyUI/models/conds/ - the custom model folder this pack registers for itself. The tensor is stored float32, keyed by the encoder name you picked, and the filename gets an auto-incremented counter (te_conds_t5xxl_00001.safetensors, then _00002, and so on) so it will never silently overwrite an existing save.

The inputs that matter:

• conditioning - the output of your text-encoder node. This is what gets flattened and saved.
• text_encoder - t5xxl or umt5xxl. This becomes the key inside the file and the tag in the filename, and the loader checks it, so match it to the encoder you actually used.
• filename_prefix - default te_conds. The save lands as {prefix}_{encoder}_{counter}.safetensors; you can include a subfolder path like myproject/main and it'll be created under models/conds.

There are no outputs - it's an output node (its only job is to write the file and report). After a save, the loaders' embedding_name dropdowns pick the file up on refresh.

Why bother, concretely. For a long, fixed prompt on a model with a big text encoder, the save/load round trip turns every repeat run into "read a file, skip the encoder." That matters most on Wan, where the UMT5 pass competes with video VRAM you'd rather give the sampler. It's also a way to hand someone a prompt's conditioning without handing them your whole workflow - the file is the encoded prompt.

Installing. One of six nodes in silveroxides/ComfyUI_CondsUtils, a WIP conditioning toolkit with an empty README and zero dependencies beyond what ComfyUI already ships (no requirements.txt, no model downloads). ComfyUI Manager → search "CondsUtils", or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI_CondsUtils

then restart. Same author handle as the Chroma GGUF quants on HuggingFace and ComfyUI_SamplingUtils - the pack is one person's toolkit, so don't expect an elaborate changelog.

Where people get burned. First, the encoder dropdown is a promise: save under t5xxl, load under umt5xxl, and the loader errors on a missing key. Second, the auto-increment means a folder full of _00001.._00037 files as you iterate - nothing overwrites, so sweep the conds folder when a prompt changes or you'll load a stale cache and wonder why the output doesn't match your new words. And remember this saves one encoder's stream: it's a piece of a Flux or SD3.5 conditioning, not the whole thing, so pair it with LoadTEConds/InsertTEConds the way the pack intends rather than expecting a complete prompt replacement.