Rename Embedding Keys

Batch-renames the tensor keys inside an embedding file and saves the result as a new .safetensors. It's the naming-fix sibling to Prune Embedding Keys in silveroxides' ComfyUI-ModelUtils pack - same author who ships the Chroma-GGUF quants a lot of people run without realizing it, same "edit the file directly instead of writing a Python script" philosophy.

Why rename a tensor key at all. Two real reasons come up. The trigger word convention: an embedding's key name is often tied to how it gets invoked, and if you're merging embeddings, standardizing an inherited or awkward vocabulary token to something cleaner is a legitimate cleanup step. The other is compatibility naming - different tools and eras of tooling have used slightly different key-naming conventions for the same underlying tensor, and a loader that's strict about naming can choke on a file that's functionally fine but named "wrong" for that loader's expectations. Renaming fixes the label without touching the actual learned vector.

How it works. Loads the embedding, walks the key list, swaps every key matching an entry in old_keys for the corresponding entry in new_keys, and writes a new file. Nothing about the underlying tensor values changes - this is a label edit, not a retraining or a merge. Your source file is left untouched.

Inputs that matter. embedding is the source file. old_keys and new_keys are both multiline fields, and the sane way to use them is one key per line, with line N of old_keys mapping to line N of new_keys - the node isn't going to guess a pairing any other way. output_filename defaults to renamed_embedding. The output is output_path, telling you where the renamed copy landed.

Installing it. ComfyUI Manager, search "Model Utility Toolkit" - or clone by hand: cd ComfyUI/custom_nodes && git clone https://github.com/silveroxides/ComfyUI-ModelUtils, restart ComfyUI. No extra dependencies, no models to fetch; it operates on embeddings you've already got.

Do the dry run first. Before you batch-rename a dozen keys across a file you can't easily reconstruct, run this pack's Get Embedding Metadata & Keys node on the source first and confirm you're spelling old_keys exactly right. A mismatched old key just gets skipped silently rather than erroring - you'll get an output file, it just won't have done what you expected, and you might not notice until something downstream breaks. If you're renaming more than one or two keys, test with a single pair first to confirm the ordering assumption holds before you commit to a full batch.

What renaming can't do. It doesn't change what encoder an embedding was trained against. Embeddings are bound to the exact text encoder used at training time - SD 1.5's CLIP ViT-L/14, SDXL's OpenCLIP, or nothing at all on the Qwen3/Mistral-class encoders current architectures like Z-Image and Flux 2 actually use. If an embedding does nothing when loaded, that's almost always an architecture mismatch, and no amount of key renaming fixes it - ComfyUI just quietly ignores an embedding it can't apply, with no warning, so it's easy to assume a rename "worked" when actually the file was never being read in the first place.

Execution gotcha. This node isn't marked as a workflow output, so if output_path isn't wired to something downstream - a Show Text node, anything - ComfyUI's graph pruning can drop the branch and skip running it altogether. Always connect the output before queuing.