VAEDecode

This one's simple to explain and slightly odd to find here: it's functionally the same node as ComfyUI core's built-in VAEDecode. Same two required inputs - samples (a LATENT) and vae (a VAE) - same single IMAGE output. If you already know how the standard VAE decode step works, you already know how to use this one; there's no difference in what it does.

The obvious question is why a pack about LLM agents ships its own duplicate of a core diffusion node at all. The most plausible reason: LLM Party's README credits lllyasviel's Omost project - an LLM-drives-image-layout system - in its "loan list," and the pack builds its own self-contained image-generation workflows around that kind of LLM-directs-diffusion idea. Bundling its own decode step means those example workflows and internal image pipelines don't depend on assuming ComfyUI core's node is present or unmodified. That's a reasonable guess, not a documented fact - the practical upshot for you is the same either way.

Inputs and outputs that matter

• samples - the LATENT to decode, same as any standard sampler output.
• vae - the VAE to decode with.
• IMAGE - the single output, a normal decoded image.

Installing it

Search comfyui_LLM_party in ComfyUI Manager and install, or clone by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

pip install -r requirements.txt inside your ComfyUI Python environment, then restart. No model download is needed for the node itself - you supply the VAE, same as always - but it comes bundled with the rest of this large pack, whose overall dependency list (LLM API clients, local model loading, RAG, TTS, and more) is considerably heavier than what this one node alone would need. The README's only_api branch trims that down if you only want API-based LLM calling.

Common issues

There's genuinely nothing special to troubleshoot here that wouldn't also apply to ComfyUI's regular VAEDecode - a mismatched VAE (wrong architecture for the model that produced the latents) or malformed latents from upstream will misbehave the same way they would with the core node.

The one thing worth being deliberate about is which decode node ends up in a given workflow. If you're building a fresh graph from scratch, there's no functional reason to reach for this one specifically over ComfyUI's built-in VAEDecode - use whichever is already convenient. Where this node actually matters is when you've dragged in one of LLM Party's own example workflows and it's already wired in; in that case, leave it as-is rather than swapping it for the core node out of habit, since there's no benefit to changing it and it's one less thing to verify still works.