Preview

The schema for this node is one line long: MODEL in, MODEL out. It patches the model and passes it straight through, and its job is to get you a live preview of the render as it happens - "Preview override for CFG Sculptor," in the pack's own words, with the README crediting Kijai's reference node for showing how to build a standalone preview node.

The reason it exists as a separate node rather than something baked into the sampler is that CFG Sculptor Advanced is a sampler. It runs its own denoise loop instead of going through the stock KSampler, so the stock preview plumbing - the stuff behind ComfyUI's preview-method setting - doesn't come along for the ride. You insert this on the model wire to get it back.

Why that's not just cosmetic

For a node whose entire premise is "explore what dynamic CFG does to an image," the preview is the feedback loop. Watching a run that's going to burn shows you it's burning at step 12 - before you've spent the rest of the render finding out. That's a different thing from seeing the finished result and guessing which part of your curve was wrong.

Where to put it:

CheckpointLoader ──► Preview ──► CFG Sculptor Advanced (model)
                              └► (same model wire, all branches)

Order doesn't matter much as long as it's upstream of the sampler - the patch rides on the model object. It does not consume the MODEL, it hands it back, so you can chain it with LoRA loaders and other model patches freely.

Preview vs. snapshots - pick one

Here's the opinionated part: CFG Sculptor Advanced already has three snapshot outputs (snap1_step, snap2_step, snap3_step, defaults 5/10/15) that decode intermediate latents into real IMAGEs. If you want to know where in the run things went wrong, snapshots are the better tool, because you end up with files you can keep, compare side by side, and re-check tomorrow. The live preview is transient - you watch it and then it's gone.

So: Preview is for sitting there tuning an envelope and seeing the effect immediately. Snapshots are for diagnosing what you tuned. On a long run, use snapshots and skip the preview entirely, because a preview is a decode on every step and steps are where your time goes.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Rimor-dev/ComfyUI-CFG-Sculptor
# restart ComfyUI

As above, the README's own clone URL says Rimor/ rather than Rimor-dev/ - use the repo URL, or install via ComfyUI Manager by searching ComfyUI-CFG-Sculptor. Dependencies are torch and numpy only; nothing to download. Recent ComfyUI with comfy_api support is required, since the pack is written against the newer backend node API.

If the preview never shows up

Nothing here is exotic - it's a model patch, so a missing preview almost always means one of three unglamorous things.

Nothing to preview. If the sampler isn't wired to an output node at all, ComfyUI may not execute the graph. Confirm your run is actually in progress before blaming the preview.

Frontend trouble, not sampler trouble. The preview arrives over a WebSocket and is drawn by the frontend, and the Nodes 2.0 canvas rewrite has been breaking third-party visual features across the ecosystem for a while. If the CFG graph draws but no image appears, or vice versa, switch back to the legacy canvas and try again - that rules the frontend in or out in one run. Open the browser console if you want to know which side failed; a WebSocket error is a frontend issue, silence is a graph issue.

Step time, not a bug. A per-step decode costs something, and on a flow-matching model running 8 steps the preview can be a noticeable fraction of the run. If the whole thing feels slower than it did, turn the preview off and compare before you go looking for a problem. And keep the honest caveat in mind: this pack is experimental with very little community traffic, so if you find something genuinely broken, there's no thread to check - reduce it to the smallest graph that reproduces it.