Noise Capture Request (Internal)

You will never place this node. If you go looking for it in the Add Node menu you may not even find it - it's flagged internal. It exists because of a genuinely awkward ordering problem inside the pack's noise reuse feature, and understanding it explains most of that feature's quirks.

The problem it solves

When you reuse noise across a hires pass, the receiving sampler has to ask the source sampler for noise at one exact noise level: whatever sigmas[0] works out to for the receiving sampler's own schedule. That number is not knowable from the receiving node's widgets alone. It depends on the model (flux family schedules are normalized differently), the scheduler, the sampler, the step count, the denoise strength, and - for resolution-dependent schedules - the geometry of the resize chain between the two samplers. Guess it wrong and the "reused" noise lands at the wrong level, which is exactly the silent-quality-loss failure mode the feature is built to avoid.

So the planner computes it properly, using the same schedule code the sampler itself will use, and hands the exact coordinate upstream.

Inputs and outputs

• model - the receiving sampler's model, which carries the schedule parameterization.
• source_latent - the original latent, used only for schedule geometry. It isn't sampled.
• steps, sampler_name, scheduler, denoise - the receiving sampler's own settings, copied in when the graph is rewritten.
• geometry_json - the validated list of resizing operations between source and receiver, so a resolution-dependent schedule can be planned at the right size.
• options (optional) - the receiving sampler's chain of sampler options, so the planner sees the same configuration the sampler will.
• previous (optional) - other receivers that share this source sampler. Requests chain through here, and the output is the merged set of coordinates.
• requests - the output: the exact source capture coordinates the originating run needs to save.

Install

You don't install it separately - it ships with the pack, and it appears in your prompt only after the pack's validation hook rewrites the graph.

cd ComfyUI/custom_nodes
git clone https://github.com/Artificial-Sweetener/SimpleSyrup.git
cd SimpleSyrup
../../venv/bin/python -m pip install -r requirements.txt

Restart afterward. ComfyUI Manager users can search the Node Pack list for SimpleSyrup and hit install instead.

Why it's a node at all

The obvious alternative is to compute the coordinate in Python during prompt preparation and stash it somewhere. SimpleSyrup deliberately doesn't do that for the value that matters: it builds a real node and wires it into the graph, so the calculation is part of the cached execution graph. Consequences you'll notice in practice:

• The capture request sits in the source sampler's model dependency chain, so it is evaluated before the source samples. No first run that saves the wrong level, then a second run that fixes it.
• Because caching keys off the node's inputs, changing the receiving sampler's steps or denoise invalidates the capture and the whole thing re-runs correctly.
• Multiple receivers reaching back to the same source point chain together, and the source saves one state per requested coordinate.
• It's inspectable. Open the graph JSON and you can read the requested coordinate's inputs instead of trusting a hidden global.

When it can't plan - no usable source sampler reachable, geometry it doesn't recognize - the failed request is replaced by a validation node that errors with a readable message. That's the failure path you'll actually see, and it means "fix your wiring", not "your noise reuse silently degraded into a normal second pass".