ForgeNeo Bridge Discard Penultimate Scheduler

ForgeNeo Bridge Discard Penultimate Scheduler does one thing: it builds a ComfyUI sigma column and deletes the second-to-last value. That's it. It's also the difference between a Forge image that reproduces and one that's been "close enough" for months, which is a lot of weight on a three-input node.

Why a sigma row matters

The sigma column is the noise level at each denoising step. Change one row and every subsequent step denoises from a slightly different place - same sampler, same seed, visibly different image. Forge has a long-standing option, discard next to last sigma, that removes the penultimate entry (sometimes regenerating at N+1 and dropping the second-to-last so the step count stays honest). It's most associated with the DDIM and SDE families, where the terminal steps get crowded, and it's one of the many small Forge behaviours that a stock ComfyUI KSampler has no widget for.

So when a Forge PNG was generated with that flag and you rebuild the graph in ComfyUI, the numbers on screen all match and the output still drifts. This node is the missing row.

Inputs and output

Four required inputs, one output. model (it needs the model's sigma sampling object to build the curve), scheduler (nine options - simple, sgm_uniform, karras, exponential, ddim_uniform, beta, normal, linear_quadratic, kl_optimal), steps (1–10000), and denoise. Output: SIGMAS.

Under the hood it's plain ComfyUI work plus the deletion: it computes the schedule for steps (scaled up by 1 / denoise when denoise is below 1), concatenates all but the second-to-last entry with the terminal value, and returns the last steps + 1 of the result. denoise = 0 returns an empty sigma tensor rather than a pretend one.

The scheduler names come from your ComfyUI install's own list, so they're Comfy's names, not Forge's. If a Forge infotext says Uniform or DDIM, you want normal or ddim_uniform here - the same mapping the pack applies elsewhere. And yes, Beta is in the list for a reason: this node exists because a specific schedule got mangled, so it takes the unusual ones.

Wiring it

SIGMAS doesn't go into a KSampler - that node builds its own sigmas and ignores an incoming column entirely, which is the classic "I connected it and nothing happened" moment. It goes into SamplerCustomAdvanced:

ForgeNeo Bridge Scheduler ──SIGMAS──> SamplerCustomAdvanced (sigmas input)
your MODEL ──────────────────────────> SamplerCustomAdvanced (model input)

Also note you supply model to both the scheduler and the advanced sampler, which looks redundant and isn't - the sigma curve is derived from the model's noise schedule.

This is the path the pack itself uses when a standard-node recipe needs the discard behaviour reproduced: ForgeNeo Bridge Settings has a discard_penultimate checkbox, and on that route the bridge wires a standard SamplerCustomAdvanced fed by this node. If you're hand-building, the setting equivalent is simply picking this node instead of a stock scheduler and feeding the advanced sampler.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-ForgeNeo-Bridge.git

Restart ComfyUI and reload the browser. No pip step, no downloads, no global sampler patches - the pack only reads ComfyUI's schedule function, never replaces it. Update with git pull --ff-only.

Limits worth knowing before you rely on it

It's ComfyUI's curve with a row removed, not Forge's curve. The pack is explicit that Forge's own scheduler implementations differ from Comfy's in more ways than the last-two-sigmas trick, and that it isn't going to silently substitute one for the other. If your Forge PNG used a Forge-only schedule (Polyexponential, Align Your Steps, Turbo, Bong Tangent, FlowMatchEulerDiscrete and friends), the brand-new SamplerCustomAdvanced route this node serves isn't the fix - that belongs on the pack's Forge compatibility path inside the main sampler, not on a hand-wired standard graph. ComfyUI does have PolyexponentialScheduler, AlignYourStepsScheduler and SDTurboScheduler nodes, but the pack's docs say those aren't numerically the same thing and it won't pretend otherwise.

Flux.2 is a known hole. The pack's reference notes say the discard request is not reproduced on the Flux.2 dedicated-scheduler recipe. If you're bridging a Flux.2 image, don't expect this node to close that gap.

steps here is not your sampler's steps. Set the same value in both places or the sigmas you built won't line up with the loop consuming them, and you'll conclude the node is broken when it's just out of sync.

Use it when you have a specific Forge image with that flag and you want the row gone. Don't use it as a general vibe knob - that's what the other sixteen schedulers are for.