EmAySee Get Model Path

You've got a model loaded into your graph and you want to know which file it actually is - for a log, for a metadata stamp, or to prove that run used the Q8 or the fp16 copy. That's what this node is for: feed it a MODEL, get the file path back as a string. It's a tiny convenience node, and it works - most of the time. The honest part is that it's reaching into a non-standard attribute to get that path, and the author's own comment in the code says "we assume the first path is the one you need." That assumption is the whole story.

How it works

The implementation is one line: model.model_filenames[0]. ComfyUI's loaded model objects carry a model_filenames attribute in some load paths (checkpoint and most loader types populate it with the file(s) that produced the model), and this node grabs the first entry and returns it as a STRING.

Here's the catch: model_filenames is not a guaranteed, documented property of every MODEL object in ComfyUI. Different loaders populate model metadata differently, and a model produced by an unusual loader, a merged model, or a diffusers-style load may not have that attribute - in which case this node raises an AttributeError and the graph errors out. It's a "works in the common case" node, not a "works in every case" node. If you use it and a workflow suddenly fails at this node, that's the first thing to suspect.

Inputs and outputs

• model (MODEL) - wire it from your checkpoint/UNET loader.

Output: model_path (STRING) - the first entry of the model's filename list. Feed it into a text display, an EmAySee_ImageLogger entry, or any text consumer.

Install

Part of ComfyUI_EmAySee_CustomNodes. ComfyUI Manager → search "EmAySee" → install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/EmAySee/ComfyUI_EmAySee_CustomNodes

No dependencies, no models. Restart and you'll see the pack's "SPECTRE v5.0" banner in the console.

The honest take

For logging which checkpoint produced an image, this is convenient - drop it in, stamp model_path into your run log, done. But given the fragile attribute access, I'd treat it as a nice-to-have rather than a load-bearing part of a production workflow. If you need the model filename reliably, the more robust move is to capture it where it's actually known - at the loader node, or from the checkpoint's name widget - rather than asking the model object to remember it. Worth reaching for when it works, worth removing the moment it errors.