Load TE Embedding and insert to conds by splicing

The text encoder is often the slowest thing in your workflow that isn't the sampler. On Flux and SD3.5-class models that's T5-XXL, a ~4.7B-parameter encoder that has to parse your whole prompt; on the Wan video family it's UMT5-XXL, the same job with a different accent. If you've ever run the same prompt across ten seeds or twenty LoRA tests and watched the encoder re-chew those tokens every single time, you know exactly what this node is for: it lets you encode a phrase once, save the embedding to disk, and then splice that saved embedding into a fresh conditioning without ever touching the text encoder again.

InsertTEConds is the "insert" half of a save/replay pair (see SaveCondsEmb for the save half). It loads a precomputed embedding file, drops its trailing end-of-sequence token so the splice doesn't inject a stray EOS into the middle of your sequence, and inserts the rest into your live conditioning at insert_at_index - default 1, which is right after the start token.

The inputs that matter:

• conditioning - the live encoding you're inserting into. This one still comes from a normal CLIP/Text Encode node; the saved file is the part you're injecting, not a replacement for the whole prompt.
• text_encoder - t5xxl or umt5xxl. This must match how the file was saved, because the safetensors is keyed by that name internally. Pick wrong and the loader fails on a missing key.
• embedding_name - dropdown populated from ComfyUI/models/conds/, the folder this pack registers for its own storage.
• strength / strength_type - same pair as the pack's other insert node: multiply scales the inserted embeddings by strength (1.0 default, −10 to 10), while attn_bias adds log(strength) to the attention-mask rows and columns of the inserted block, so the model attends to it more or less strongly without changing the embedding magnitudes.
• insert_at_index - default 1, range 0–4096. Where in the token stream the saved block lands.

Output is a single CONDITIONING, sampler-ready.

What it's actually good for. The pure-play case is a long, fixed prompt that you re-encode constantly - cache it once, splice it in every run. The sneakier case is mixing encoders: encode a phrase with a text encoder you don't want resident (T5-XXL is gigabytes of VRAM you can drop after the save) and inject its tokens into a conditioning produced by whatever's cheap to keep loaded. It's a very "I know exactly what I'm doing" node - the kind of thing the author clearly built for their own Wan video loops, where the UMT5 pass is a real chunk of the pipeline.

Installing. One of six nodes in silveroxides/ComfyUI_CondsUtils - a WIP conditioning toolkit whose README is basically empty (the code is the documentation). ComfyUI Manager → search "CondsUtils", or:

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

then restart. No requirements.txt, no model files to download - it's all torch and comfy.utils. Same author handle behind the Chroma GGUF quants on HuggingFace and ComfyUI_SamplingUtils.

Where people get burned. The classic trap is a key mismatch: saved as t5xxl, loaded as umt5xxl, immediate error. Also remember the file holds only that encoder's tokens - if your model expects multiple encoders (Flux wants T5 plus CLIP-L, SD3.5-L wants three), you're splicing one stream into a live conditioning that supplies the rest, which is correct. Don't feed a saved file to LoadTEConds and pretend it's a complete Flux conditioning - it isn't. And since the save nodes never overwrite (they auto-increment _00001, _00002…), your models/conds folder quietly fills up; sweep it when you iterate on a prompt.