Recipe Renderer

Recipe Renderer (class RecipeRenderer) is the pay-off node of the whole Recipe toolset: give it a RECIPE_DATA payload and it loads the models, runs the sampler, decodes, and hands you an image. No graph spaghetti, no re-setting KSampler values by hand - the recipe carries everything and this node executes it. It's the closest thing in the pack to "one node does the whole generation."

How it works

One required input: recipe_data (from Recipe Builder, Recipe Extractor, or Prompt Extractor). The node reads the selected model slot, loads the model (plus CLIP and VAE), resolves the LoRA stack, applies the recipe's prompts, sampler settings, resolution, and seed, samples, decodes, and outputs:

• output_image - the rendered IMAGE
• output_latent - the latent for post-processing or chaining
• recipe_data - the payload, forwarded (with runtime objects stripped) so you can save or rerun it

The model_slot selector (default model_a) picks which of the recipe's up to four model blocks renders. For image-to-video (WAN Video i2v), connect a source_image to the optional input. And clear_cache_after_render does what it says: after rendering, it clears the renderer's model cache and asks for a memory cleanup - the switch to flip when you're rendering several recipes in one session and VRAM is tight.

The notable mechanic is the family-aware defaults. The renderer knows each model family's intended sampler setup - SDXL gets dpmpp_2m_sde/karras with CFG 5, Flux gets euler/simple at CFG 1, WAN video defaults to a fast LCM 2-step config, and so on. It applies those family defaults over whatever the recipe carries, which means recipes are portable across families without you hand-tuning samplers: render a WAN video recipe and you get the settings that family wants, not whatever a previous recipe left behind. GGUF model support rides on ComfyUI-GGUF if you have it installed.

Why it exists

It's the "reproducibility without rebuilding the graph" play. Extract a recipe from an image you like, tweak it in Builder, and render - the whole pipeline is captured in data, so rerunning or sharing it is just passing the payload around. The author's suggested flow is Builder (or Extractor) → Renderer → Recipe Manager to save the winners. If you're the kind of person who wants to retain full control of sampling and post-processing, Recipe Relay is the alternative that hands you the parts instead; the Renderer is for when you trust the template and want the result.

Installing

Part of the ComfyUI-Prompt-Manager pack:

cd ComfyUI/custom_nodes
git clone https://github.com/FranckyB/ComfyUI-Prompt-Manager.git
cd ComfyUI-Prompt-Manager
pip install -r requirements.txt

Or ComfyUI Manager → search "Prompt Manager", then restart.

Gotchas

The family-default normalization cuts both ways: it's the reason recipes render correctly across model types, but it also means your custom sampler overrides in a recipe can be overridden again by the family defaults - if you deliberately set an unusual sampler and the renderer "helpfully" resets it, that's why. Also, the renderer is only as good as the recipe: an empty or partial recipe renders with defaults, and a recipe naming models you don't have will fail at load time. And because it does everything internally, debugging a bad render is harder than with a normal graph - when something's off, check the recipe data first, not the node.