NS Refiner Boundary Optimizer

In the classic SDXL base → refiner pipeline, someone has to decide the switch step: the moment the base model stops denoising and the refiner takes over. Most workflows just pick a number (0.8 is the folk wisdom) and never revisit it. NS Refiner Boundary Optimizer is a full sampler node that replaces that guess - it runs the base model, watches how the image is actually developing, and picks the handoff point based on what it sees. Then it runs the rest of the generation to completion. You get a finished latent and the switch step it chose.

The pitch is genuinely clever. The base model builds the coarse structure and the refiner refines detail, but the ideal handoff isn't a constant - some images lock their structure early, some keep reorganizing late. A frequency analysis of the denoised output can tell you which kind you're dealing with. That's the core insight, and this node operationalizes it.

How it works

It's a three-phase sampler, all inside one node:

1. Analysis pass - runs the base model for up to max_base_ratio (default 0.9) of the steps, tracking two metrics per step: frequency (the high-frequency energy of the predicted image, via a Laplacian filter) and stability (how much the prediction changes between steps).
2. Decision - picks the switch step by detecting where those metrics saturate, bounded between min_base_ratio and max_base_ratio (defaults 0.5–0.9). evaluation_metric chooses frequency, stability, or combined; sensitivity (0–1, default 0.5) controls how eagerly the detector declares "this is where structure stops changing." Higher sensitivity = earlier switch.
3. Real run - runs the base model to the chosen step, then the refiner the rest of the way, reusing the analysis pass's output when the decision lands at the max so you don't pay for a wasted second base run.

You feed it both models, both prompt sets (positive/negative for base, positive_refiner/negative_refiner for refiner), the latent, and standard sampler settings (steps, cfg, sampler_name, scheduler, seed, denoise). Outputs are the finished LATENT and the chosen switch_step as an INT - the second output is the interesting one, because it tells you what the node decided.

Where it hurts

The honest cost: in the common case it runs the base model twice (analysis to max, then real run to the switch step). That's roughly 1.5–2x the base-model compute of a normal fixed-switch workflow, before the refiner even starts. On a fast card it's tolerable; on a 3060 it's a real time sink. The sensitivity knob exists to help - lower it and the detector switches earlier, so the second base run is shorter - but you're trading time for an adaptive decision.

Also set expectations: "optimizer" sounds like it finds a better image. It finds a better timing. If your base and refiner conditioning aren't well-set-up (and remember the community largely abandoned the refiner - the KB's verdict is "shipped, then ignored"), no amount of boundary optimization fixes that.

Installing it

Part of ComfyUI-NS-Util:

cd ComfyUI/custom_nodes
git clone https://github.com/NakamuraShippo/ComfyUI-NS-Util

or ComfyUI Manager → Install via Git URL with the same URL, restart. No model downloads - it needs the base and refiner checkpoints you already have - and the dependencies are the pack's light set.

The honest take

This is the most ambitious node in the pack: a full replacement sampler with an adaptive decision inside it. The idea - let frequency/stability saturation pick the handoff - is sound and genuinely under-explored. But it's also a time-expensive tool for a pipeline (base + refiner) that most of the community has moved on from. If you're deliberately keeping the two-stage workflow alive and want to stop hand-tuning the switch step, this is the only tool I know that does the job automatically. Just budget the extra compute.