Rename Diffusion Model Keys

Batch-renames tensor keys inside a diffusion model checkpoint and saves the result as a new file. It's the naming-fix half of silveroxides' ComfyUI-ModelUtils Keys tools, applied here to full checkpoints instead of LoRAs or embeddings - and it's solving a genuinely common problem: the same underlying weights getting different tensor key names depending on which tool exported them.

Why key names diverge at all. This isn't hypothetical or pack-specific - different training and inference stacks in this ecosystem have used different naming conventions for the same tensors (the "diffusers" format versus the "original"/checkpoint format prefixes being the most familiar example anyone who's converted a model has run into). A checkpoint that's functionally complete and correct can still fail to load, or partially load with warnings, if its key names don't match what a specific loader expects. Renaming fixes the label without touching a single learned value.

How it works. diffusionmodel_name picks the source checkpoint. It loads the full file, and for every key matching an entry in old_keys, swaps it for the corresponding entry in new_keys, then writes the result to a new file. The underlying tensor data is untouched - this changes what the weights are called, not what they are.

Inputs that matter. old_keys and new_keys are both multiline fields, and the working assumption is one key per line with line N of old_keys mapping to line N of new_keys - the node has no other sensible way to pair them up. output_filename defaults to renamed_model. The output, output_path, tells you where the renamed copy landed.

Installing it. ComfyUI Manager, search "Model Utility Toolkit" - or cd ComfyUI/custom_nodes && git clone https://github.com/silveroxides/ComfyUI-ModelUtils, restart. No extra dependencies flagged in the README.

This is a heavy operation. Full checkpoints run 2-12GB, and this node loads the entire file to do its work - there's no lazy_load option here the way the LoRA and extraction nodes offer, so plan for real load time and real memory use, especially on a large model. It's not something you'll want to iterate on rapidly; get your old_keys/new_keys list right before you commit to a full run.

Test the pairing before you commit. If you're renaming more than a key or two, do a single-pair test run first and confirm the line-based pairing assumption holds and the output loads correctly, before batch-renaming a dozen keys across a multi-gigabyte file you can't cheaply regenerate if something goes sideways. A mismatched old_keys entry doesn't error - it's simply skipped, so a typo means part of your rename silently didn't happen.

What renaming can't do. It relabels tensors; it doesn't reconcile a checkpoint's actual architecture with a loader that expects a fundamentally different one. If a model still won't load correctly after a rename, the problem is more likely a genuine structural mismatch - extra or missing layers, a different number of blocks - not just naming, and no key rename fixes that.

Execution quirk. This node isn't marked as a workflow output, so output_path needs to be wired to something downstream - a Show Text node, anything - or ComfyUI's graph pruning may skip running it altogether.