Get Text Encoder Metadata & Keys

The least glamorous of this pack's three "MetaKeys" nodes, and probably the one with the narrowest audience - but if you're doing anything with standalone text encoder files (CLIP, T5, Qwen3, whatever your architecture uses), this is the tool that shows you what's actually in one. The node's own description is direct: it "loads a text encoder and returns its metadata and layer names."

What it does

One input, textencoder_name, a dropdown of the encoder files ComfyUI knows about. Two string outputs: metadata (the safetensors header, whatever the file's source chose to write there) and keys (every tensor's internal name). No transformation, no interpretation - this is a read-only inspection tool.

Why you'd need it

Text encoders stopped being a small, uniform CLIP tower a while ago. Current architectures condition on genuine language models - Z-Image names its encoder Qwen3Model, Flux.2 Klein and Krea 2 use Qwen3-VL - and that shift changed what a "text encoder file" even contains. If you're troubleshooting a workflow where swapping encoder files produces broken output, or you're about to run TextEncoderTwoMerger on two encoder files and want to sanity-check they're actually from compatible architectures before you commit VRAM and time to a merge, this is where you'd look first: check that the key structure and any metadata actually line up before assuming two files labeled similarly are interchangeable.

It's also just useful for the basic "what is this file" question. Text encoder files aren't always clearly labeled by their source - a bare .safetensors named after the architecture doesn't always tell you the exact variant, precision, or training lineage, and this node is the fastest way to look without leaving ComfyUI.

Installing it

ComfyUI Manager: search Model Utility Toolkit, install, restart. Or:

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

Restart ComfyUI. No downloads needed - it reads a file already on your disk.

Where people get burned

Same honest caveat as the checkpoint and LoRA versions of this node: a lot of text encoder files carry a thin or empty metadata header, so don't read a blank result as a bug. The keys output is the more reliable signal - a genuine T5/Qwen-class language-model encoder will have a visibly different, much larger key structure than an older CLIP tower, and that difference alone is usually enough to catch a mismatched-architecture mistake before it costs you a merge or a broken workflow. If two encoder files you expected to be compatible produce wildly different key lists here, that's your answer for why swapping one for the other in a workflow didn't work - no error message needed, the schema itself already told you.