Sampler Params Context
Override just what you connect — sampler params that only change what you touch
- sampler_params
- sampler_params
- sampler
- scheduler
- steps
- denoise
- seed
- cfg
Here's the workflow problem Sampler Params Context solves: you've got a base sampler configuration - say DPM++ 2M, karras, 28 steps, cfg 7 - and you want to run a pass that's identical except for one value. The naive approach is a second full Sampler Params node where you retype all six settings and hope you copy them right. This node lets you connect only what you want to override, and it rebuilds the bundle around your base.
It works exactly like a "context" node should: reflect only the inputs that are actually connected. Connect nothing, and it mirrors a base sampler_params through untouched. Connect a seed from elsewhere, and you get the full bundle back with just the seed swapped. Connect a denoise, same deal. Every connected field overrides; every unconnected field stays whatever the base said.
Inputs and outputs
All inputs are optional, which is the entire point:
- sampler_params - the base bundle to build on (optional; if you leave it disconnected and only wire individual fields, it constructs from those).
- sampler, scheduler, steps, denoise, seed, cfg - the per-field overrides. Each is an optional socket; connect any subset.
The outputs mirror the inputs, so this node also works as a splitter when you need the bundle loosened up: sampler_params (the rebuilt bundle) plus individual sampler, scheduler, steps, denoise, seed, cfg outputs, each typed for whatever downstream node expects it.
This makes it the natural place to inject variation in iterative workflows - a per-seed loop, a cfg sweep, an XY plot where one axis changes denoise while everything else stays fixed. Feed the base bundle in once, let the loop drive a single socket.
What it's not
It's not a validation layer and not a math node. Values pass through normalized but untouched - set cfg to 12 and it stays 12, even if that's a silly number for your model. The "context" behavior only cares about whether a socket is connected, not what the value is. And while it can split a bundle into parts, if you purely want bundle → six outputs with zero override behavior, Split Sampler Params is the leaner node for that job.
Install
Same pack as everything else here:
cd ComfyUI/custom_nodes
git clone https://github.com/kinorax/comfyui-info-prompt-toolkit.git
cd comfyui-info-prompt-toolkit
pip install -r requirements.txt
Or ComfyUI Manager → search "ComfyUI-Info-Prompt-Toolkit" → install → restart. No models, no special dependencies beyond the pack's base install.
Where people get burned
The subtle one is expecting the override logic to apply to values you typed into the widget and connected. It doesn't work that way: the node inspects what's wired in the graph, not what's sitting in its own widget boxes. If you type a seed into the node's widget and also connect a seed from elsewhere, the connected value wins, and the widget is effectively dead - which is the standard ComfyUI "connected input beats widget" rule, but it trips people up more here because every input is optional. And remember the base-bundle behavior: if sampler_params isn't connected and no individual fields are connected, you'll get an empty bundle out, so don't expect defaults to materialize from thin air.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| sampler_paramsopt | IPT-SamplerParams | — | |
| sampleropt | STRING | — | |
| scheduleropt | STRING | — | |
| stepsopt | INT | — | |
| denoiseopt | FLOAT | — | |
| seedopt | INT | — | |
| cfgopt | FLOAT | — |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| sampler_params | IPT-SamplerParams | — |
| sampler | * | — |
| scheduler | * | — |
| steps | INT | — |
| denoise | FLOAT | — |
| seed | INT | — |
| cfg | FLOAT | — |