PromptGenerationConfig

Normally your generation settings live on their own separate nodes - an Empty Latent Image here, a KSampler there - completely disconnected from whatever prompt happens to be running through them. That's fine until you're batching a big list of prompts (a wildcard file, a "load lines from a text file" setup, anything with real per-line variety) and different lines genuinely want different settings: this one's a portrait at a high step count, that one's a quick landscape test at low steps with a different sampler. PromptGenerationConfig lets you attach those settings to the prompt itself, as a small tag you type inline, instead of hand-configuring a separate sampler chain for every variant.

How it works

The node exposes the usual generation knobs as widgets - width, height, steps, cfg, sampler_name, scheduler, denoise - plus a multiline prompt input. Wire your prompt text (a wildcard line, or just a plain string) into prompt, and set the widgets to whatever your fallback values should be. If the prompt text contains a <config:...> tag, the node reads it and overrides whichever settings you named on top of your widget defaults; if it doesn't, your widgets pass straight through untouched. The tag format, per the pack's own docs:

<config[:swap][:key1=value1[:key2=value2...]]>

Valid keys are width, height, steps, cfg, sampler_name, scheduler, and denoise - the same names as the widgets. Add swap on its own and the node flips width and height for you, which is the quick way to alternate orientation across a batch without maintaining two separate resolution settings side by side.

The inputs and outputs that matter

You'll mostly touch width/height (default 512, the pixel size of the latent you're generating into), steps (default 20, denoising iterations), cfg (default 8, how hard the sampler chases your prompt - see the caveat below), sampler_name and scheduler (the algorithm and noise curve - pick these to match your checkpoint, not out of habit: DPM++ 2M with a Karras schedule is right for SD 1.5/SDXL, but Flux and most other flow-matching models actively dislike Karras and want Euler on a normal or beta schedule instead), and denoise (default 1, lower it for img2img-style partial denoising). The prompt field is where the <config:...> tag lives.

Outputs mirror the settings - width, height, steps, cfg, sampler_name, scheduler, denoise - wired straight into your Empty Latent Image and KSampler. Two more outputs, replaced_string and original_string, give you the prompt with the config tag stripped out (send this to your CLIPTextEncode) and the prompt exactly as it arrived, tag and all (handy to log alongside the image so you know what actually produced it).

Installing it

Via ComfyUI Manager: search comfyui-prompt-config, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/Taremin/comfyui-prompt-config

Restart afterward. No models to download and no heavyweight dependencies - this pack is pure text parsing, so if git clone finishes cleanly you're basically done.

Where people get tripped up

This one's obscure enough that you won't find much community chatter to lean on - it's a small, quiet utility node from an author who mostly builds prompt-text tooling, not a widely-discussed pack. So treat the following as mechanical, not anecdotal.

Get the tag syntax wrong - a stray space, a missing > - and there's no error, it just silently fails to match, and you fall back to whatever your widgets say. If an override "isn't working," check the tag's characters before you suspect the node.

The sampler_name/scheduler pair is a real decision here, not a formality: this node hands you 34 samplers and 9 schedulers, and the "safe default" changes depending on what you're running. Karras is correct on SD 1.5/SDXL and actively wrong on Flux and most 2026-era flow-matching checkpoints, which want a straight Euler-plus-normal/beta pairing instead. Don't carry one combination across every model in your wildcard file.

And remember cfg here is just a number the node hands downstream - it has no idea your checkpoint might be guidance-distilled. Setting cfg=7 via the tag on a Turbo- or Klein-distilled model will dutifully happen and will just make your renders slower and worse, since those models expect CFG around 1 by default. Match the value to the model, not to old SDXL habits.