⚙️ Prompt Property Extractor

The most ambitious node in this pack, and the one its own author calls out as unusually useful without much exaggeration: it lets you describe an entire generation - checkpoint, LoRAs, sampler settings, resolution, even the negative prompt - as tags embedded directly inside a single block of text, then parses that text back out into every wired connection a KSampler needs. Announcing it on r/StableDiffusion, the pack's author described the point of it as letting you drive "the Prompt Property Extractor node, and the KSampler only" for a full image, and the reason it's worth building at all is combining it with wildcards: once your whole configuration lives inside one string, randomizing any part of a generation - not just the prompt, but the checkpoint, the step count, the CFG - becomes exactly as easy as randomizing prompt text with a {a|b|c} wildcard.

The tag vocabulary is long, and the tooltip lists it exhaustively: <checkpoint:name> (or <model:name> / <ckpt:name>), <clip:name>, <vae:name>, <lora:name:weight>, <cfg:value>, <steps:value>, <sampler:name>, <denoise:value>, <width:value> / <height:value> / <resolution:WxH>, <seed:value>, <start_step:value> / <end_step:value>, and <pos:value> / <neg:value> for positive and negative prompt content - multiple <pos> or <neg> tags in one string get joined together with commas. Anything you write outside a recognized tag becomes your prompt text; anything inside an unrecognized tag format gets passed through untouched to the other_tags output instead of silently dropped.

Model-loading priority is the one thing worth reading carefully before you rely on it, because it isn't simply "the tag wins." For CLIP: a <clip:name> tag always wins outright; failing that, if a <checkpoint:name> tag is present and load_clip_from_checkpoint is true, the checkpoint's own CLIP is used; only if neither applies does the wired clip input pin get used. VAE follows the identical three-tier logic with its own load_vae_from_checkpoint toggle. This matters in practice whenever you're mixing a wired-in checkpoint with a <checkpoint:> tag in the text - the tag doesn't just add to what's connected, it can override CLIP and VAE too, depending on those two boolean settings.

Fields a beginner actually sets: input_string is where all the work happens - everything else in the required list (cfg, steps, sampler_name, denoise, width, height, seed, start_step, end_step) is just the default value used whenever the matching tag is absent from your text. load_clip_from_checkpoint and load_vae_from_checkpoint are the two toggles from the priority logic above. The optional model/clip/vae inputs are your fallback sources, lowest priority in the chain described above.

Outputs are dense, and worth reading closely because two pairs share a name across different types: there's a positive output that's a CONDITIONING (the CLIP-encoded version, ready for a sampler) and a separate positive output that's a plain STRING (the same text with tags stripped, for anything that wants the raw prompt rather than an encoding) - same story for negative. Wire by type, not by trusting the label alone. Beyond those, you get the fully resolved MODEL/CLIP/VAE, a latent sized to your resolved width/height, every numeric setting resolved (seed, steps, cfg, sampler, denoise, start_step, end_step), other_tags for anything unrecognized, and resolved_string - wildcards resolved but all tags still present, distinct from the STRING positive output which has tags stripped out entirely.

One honest limitation, straight from the author: in the post introducing this node, its creator flagged that "the only one that doesn't work properly is the Scheduler" - the sampler tags work, but scheduler selection through this parsing path is a known rough edge rather than something fully reliable yet. Worth knowing before you build a workflow that depends on tag-driven scheduler switching specifically.

Installing it: ComfyUI Manager, search "ComfyUI-mnemic-nodes," or git clone https://github.com/MNeMoNiCuZ/ComfyUI-mnemic-nodes into custom_nodes, then restart. No external dependencies beyond what the rest of the pack already needs.

Where it trips people up beyond the scheduler caveat: the model-loading priority order above is genuinely easy to get backwards the first time - if your wired model input doesn't seem to be taking effect, check whether a <checkpoint:> tag is quietly present somewhere in your input_string and overriding it. LoRA tags follow the same fuzzy-matching-by-filename rules as the rest of the pack, so a typo'd LoRA name fails silently rather than throwing an error. And if you need a literal > character inside a tag's value, the tooltip notes you have to escape it as \> or it'll be read as the tag's closing bracket.