Dynamic Threshold

DynamicThreshold takes one integer and returns a float, using a fixed lookup table. That's the entire feature set. It exists because CFG scale behaves differently at different resolutions and prompt lengths, and some workflows want to automate "bigger image → lower CFG" instead of typing it. The node hard-codes a curve: low input values map to high output values, and as the input climbs the output steps down. So far, so reasonable - but the name oversells it. There is nothing dynamic about it, and the mapping is baked in with no knobs.

How it works

You feed it input_value (an INT, 1–1000 per the schema) and it runs it through a hard-coded ladder:

• 1–150 → 7.0
• 151–200 → 5.3
• 201–250 → 4.5
• 251–300 → 3.8
• … and so on, stepping down to 0.6 for anything above 1600.

The general shape is a descending curve from 7.0 to 0.6, with a couple of flat plateaus (551–600 repeats 2.2). The intended use is obvious: feed it a metric that grows with resolution or complexity, and get a CFG value that shrinks with it - the rough community rule that big canvases need less guidance. But note the output is a FLOAT with no units, so it only becomes a CFG when you wire it into a sampler's cfg input (KSampler's cfg is a FLOAT, so it connects fine). The same node could drive denoise or anything else that takes a float; nothing enforces "CFG" except you.

The inputs that matter

• input_value - the only input, INT 1–1000 in the schema. What you map to it is your business: resolution in megapixels, prompt length, denoise strength, whatever scales with your needs.

Output is a single FLOAT.

Where it fits - and where it doesn't

If you've ever wanted "CFG that follows my image size without me re-tuning every time," this gets you 80% of the way with zero configuration. The honest caveat: the exact curve (7.0 → 0.6, with those specific breakpoints) is someone else's opinion about what CFG should look like, and it is not tuned to your model or your aesthetic. Flux models barely use CFG at all, SDXL likes a narrower band, and SD 1.5 workflows routinely run higher - so this table is really aimed at the SD-family "bigger = less guidance" crowd. Don't treat 7.0 as a universal starting point; treat it as a data point, and expect to adjust upstream (scale your input) rather than rewrite the table, since you can't.

Installing it

Part of ComfyUI-YCNodes. ComfyUI Manager → search ComfyUI-YCNodes → install, or:

cd ComfyUI/custom_nodes
git clone https://github.com/yichengup/ComfyUI-YCNodes

Restart, then look under YCNode/Logic. Pure Python - no dependencies.

Gotchas

The schema caps input_value at 1000, which means the interesting low-end tail of the table (the values below ~0.9) is unreachable from the UI - the code defines buckets above 1000 that you can never trigger with the node as wired. So effectively you get 7.0 down to about 1.2 across the reachable range. And the word "dynamic" will mislead you: if you wanted a dynamic threshold - an adaptive comparison, a working threshold that moves with the image - this is not that. It's a static lookup. For that job, you want a real logic/compare node, not this.