Get Parameters from Recipe
Get Parameters from Recipe
- recipe_params
- ckpt_name
- positive_prompt
- negative_prompt
- seed
- steps
- cfg
- sampler_name
- scheduler
- width
- height
- denoise(Hires. Fix)
You've seen a Civitai showcase image you like and thought "I want exactly that, not my best guess at it." Get Parameters from Recipe is the node that turns that wish into a running graph - it takes the exact recipe behind one specific community image and unpacks it into everything a checkpoint loader and sampler need.
It's built to pair with the pack's Civitai Recipe Gallery node: you browse a model's top images there, pick one, and the Gallery hands you back an image, a markdown report, and a recipe_params pipe carrying that one image's actual generation settings. This node is what cracks that pipe open.
Why this is possible at all
Civitai's whole design leans on this: sample images uploaded to the platform routinely carry their full generation metadata embedded in the file - prompt, sampler, LoRA weights, the works, the same way Automatic1111 and ComfyUI itself write it into PNGs. That's not incidental; the platform's own rules require at least the prompt on sexualized content and most creators leave everything in by default. This node is the direct payoff of that convention: instead of you dragging a downloaded image into ComfyUI hoping it has embedded workflow data, the Gallery + Unpacker combo does the download and the reconstruction for you.
Outputs - this is basically a checkpoint loader and a KSampler's worth of inputs in one node
ckpt_name- the checkpoint the recipe was made with. Note this only names it; you still need that checkpoint sitting locally for it to mean anything. If you don't have it, ComfyUI will flag it as missing, same as picking a nonexistent file in a normal Load Checkpoint dropdown.positive_prompt,negative_prompt- straight into your twoCLIPTextEncodenodes.seed,steps,cfg,sampler_name,scheduler,width,height- straight intoKSamplerandEmptyLatentImage.denoise(Hires. Fix)- only relevant if the recipe used a two-pass hires-fix generation. Wire it into a secondKSampler's denoise, not the first - a fresh generation from noise wants denoise 1.0, and a hires-fix second pass typically only wants something in the 0.3–0.5 range to add detail without redrawing the composition. If the recipe was single-pass, you can ignore this output.
The single input is recipe_params (RECIPE_PARAMS) - and it has to come from Civitai Recipe Gallery. It's a different pipe type from the CIVITAI_PARAMS the pack's Model Analyzer produces, even though the two nodes' outputs look almost identical on the surface. One recipe is one specific image's actual settings; the other is a statistical "what does everyone commonly do" average across many images. Don't cross the wires - they're not interchangeable, and ComfyUI won't let you connect one pipe type into the other node's socket anyway.
Installing it
Same pack, same two options - search Civitai Toolkit in ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/BAIKEMARK/ComfyUI-Civitai-Toolkit
pip install -r requirements.txt
Restart, then find it under Civitai → 🖼️ Gallery, next to Recipe Gallery.
Troubleshooting
ckpt_name (or a LoRA the recipe calls for) is missing locally. Expected, and the pack actually helps here: the Gallery/Analyzer diagnostics report missing models with a direct link to their Civitai page, the same feature that's long existed for missing LoRAs and was extended to checkpoints in a recent update. Follow the link, grab the file, drop it in the right folder, rerun.
The recipe partially fails to reconstruct on an older image. Civitai prunes and removes models routinely - its own 2024 transparency report alone logged thousands of models pulled that year - so a recipe built from a two-year-old showcase image may point at something that simply isn't there anymore. That's platform churn, not a bug in the node.
First run feels slow. The toolkit hashes your local models to match them against Civitai's records, and that happens in the background on first use so it doesn't block ComfyUI from starting - expect the first fetch to lag a bit while it catches up, then be fast afterward.
Sampler comes through but the result looks off. Civitai images get generated across multiple UIs with different sampler-naming conventions, so an A1111-style combined name doesn't always map cleanly onto ComfyUI's separate sampler/scheduler widgets. Worth a glance before trusting it blindly on an important reproduction.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| recipe_params | RECIPE_PARAMS | — |
Outputs (11)
| Name | Type | Description |
|---|---|---|
| ckpt_name | — | |
| positive_prompt | STRING | — |
| negative_prompt | STRING | — |
| seed | INT | — |
| steps | INT | — |
| cfg | FLOAT | — |
| sampler_name | euler,euler_cfg_pp,euler_ancestral,euler_ancestral_cfg_pp,heun,heunpp2,exp_heun_2_x0,exp_heun_2_x0_sde,dpm_2,dpm_2_ancestral,lms,dpm_fast,dpm_adaptive,dpmpp_2s_ancestral,dpmpp_2s_ancestral_cfg_pp,dpmpp_sde,dpmpp_sde_gpu,dpmpp_2m,dpmpp_2m_cfg_pp,dpmpp_2m_sde,dpmpp_2m_sde_gpu,dpmpp_2m_sde_heun,dpmpp_2m_sde_heun_gpu,dpmpp_3m_sde,dpmpp_3m_sde_gpu,ddpm,lcm,ipndm,ipndm_v,deis,res_multistep,res_multistep_cfg_pp,res_multistep_ancestral,res_multistep_ancestral_cfg_pp,gradient_estimation,gradient_estimation_cfg_pp,er_sde,seeds_2,seeds_3,sa_solver,sa_solver_pece,ddim,uni_pc,uni_pc_bh2 | — |
| scheduler | simple,sgm_uniform,karras,exponential,ddim_uniform,beta,normal,linear_quadratic,kl_optimal | — |
| width | INT | — |
| height | INT | — |
| denoise(Hires. Fix) | FLOAT | — |