Prune Text Encoder Keys

The same load-prune-save pattern silveroxides' ComfyUI-ModelUtils applies everywhere else, here pointed at a standalone text encoder file. That's a more relevant target than it used to be: current architectures don't bundle a small CLIP model inside the checkpoint the way SD 1.5 and SDXL did - Z-Image, Chroma, and Flux-family models load their text encoder as its own separate file (a Qwen3-class model for Z-Image, T5-XXL for Chroma and Flux), the kind of thing you pick with a DualCLIPLoader-style node rather than getting bundled automatically. That's exactly the file type this node edits.

Why prune keys from a text encoder file. The usual reasons: cutting a file down by removing tensors you don't actually load with (extra precision variants, components specific to a use case you're not using), or fixing a file that has keys wrapped or prefixed in a way a stricter ComfyUI loader doesn't expect. As with every prune node in this pack, this is a targeted removal - the tensors that survive aren't altered.

How it works. textencoder_name picks the source file from your text encoder folder. It loads the file, drops every key matching an entry in keys_to_prune, and writes a new .safetensors file. The source is untouched.

Inputs that matter. keys_to_prune is a multiline field - exact key names, one per line. use_regex switches to regex matching if you're targeting a whole family of keys by pattern rather than listing each individually. output_filename defaults to pruned_textencoder. Output is output_path.

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

Know your key names first. As with every prune node in this pack, a wrong or mistyped key in keys_to_prune doesn't error - it just matches nothing, and the file you get back is functionally identical to the source with no indication anything went wrong. Check the file's actual tensor names (reading the safetensors JSON header directly is safe and fast - it's plain text, nothing executes) before you commit to a batch prune.

Size and time matter here. Text encoders vary a lot in size depending on which one you're working with - a CLIP-L file is small, but the LLM-class encoders current architectures use (Qwen3, T5-XXL) can run into multiple gigabytes on their own. There's no lazy_load toggle on this node, so it loads the whole file into memory regardless of size - budget accordingly on the larger encoder files.

What pruning can't fix. This changes which tensors are in the file, not what encoder architecture it represents. If a text encoder isn't loading correctly in your DualCLIPLoader (or equivalent) node, that's much more likely to be the wrong encoder type or a genuine format mismatch than something a key prune will resolve.

Execution quirk. This node isn't marked as a workflow output, so if output_path isn't wired to something downstream, ComfyUI's graph pruning can skip the node entirely and no file gets written despite the save happening as a side effect. Connect the output before queuing.