Schema Float Parameter
Denoise, CFG, and strength as a contract
- value
The float is the most abused number in ComfyUI. Denoise, CFG scale, prompt weight, LoRA strength - they're all floats, they all have sensible ranges, and agents have no idea what those ranges are unless you tell them. This node is how you tell them: a FLOAT parameter where the min/max/step are part of the machine-readable contract, not vibes. Wire its value output into a KSampler's denoise or cfg, and an agent that parses your workflow learns "denoise: 0.0–1.0, default 0.5" before it burns a run on 12.7.
It's the float sibling of SchemaIntegerParameter in the ComfyUI_SchemaNodes pack, and it shares the same numeric-constraint machinery - plus one extra trick: round_to.
The inputs that matter
name/description- the usual contract-writing advice: stable identifier, description written for a machine to read ("Denoise strength for img2img. 0 = no change, 1 = full resample").io_kind-inputfor values the agent supplies,outputto surface a computed float (a chosen strength, a measured scale) back as a result.default- the fallback (0.0 by default).ge,gt,le,lt- the guardrails, mapped to JSON Schemaminimum/exclusiveMinimum/maximum/exclusiveMaximum. Defaults sit at the ±1,000,000 extremes as a "not set" sentinel - leave them and they're omitted from the schema entirely. Set only the ones you mean.multiple_of- constrain values to steps (e.g. 0.1). Maps tomultipleOf.round_to- the float-only extra. Set it to a positive N and the node rounds the actual output value to N decimal places. It's the one constraint that isn't just metadata; it mutates what flows down the graph.value_in(FLOAT, forced input) - the override; wired input beatsdefault.
How it works
At runtime it resolves value = value_in or default, coerces to float, applies round_to if set, and emits it as a FLOAT on value. The node also records a precision hint in its metadata when round_to > 0, so a schema parser knows the field is meant to be quantized to that many decimals.
The round_to behavior is worth calling out because it's the one place this pack does real work at execution rather than just declaring. If your agent tends to produce 0.30000000000000004 for "0.3", round_to=2 keeps downstream math and logging clean. Everything else - the bounds - is metadata for your tool to validate against, exactly like the integer node. If the README's promise of a SCHEMA_FIELD output confuses you: that output was removed in the current code (commit 8e5676d), so the declaration lives in the widget values inside the workflow JSON.
Installing it
One install, all eight nodes.
cd ComfyUI/custom_nodes
git clone https://github.com/Liquid-XO/ComfyUI_SchemaNodes
Restart ComfyUI, or use ComfyUI Manager (search "ComfyUI SchemaNodes"). No pip dependencies, no models, no keys.
Common gotchas
- Bounds are not enforced at runtime. Feed the node a
denoiseof 2.0 viavalue_inand it'll pass 2.0 straight through - thele/ltconstraints are declarations, not a clamp. Your tool validates. round_tois the exception to "metadata only" - and it's easy to forget. If you set it thinking it's a UI nicety, you'll be surprised that the value itself gets rounded. That's usually what you want, but it's a mutation, not a label.- The
stepon thedefaultwidget is a UI hint, not a validator. It's how ComfyUI renders the number input; it doesn't constrain what the node accepts.
Inputs (12)
| Name | Type | Default | Description |
|---|---|---|---|
| name | STRING | parameter_name | — |
| io_kind | COMBO | input | 2 options: input, output |
| description | STRING | — | |
| required | BOOLEAN | true | — |
| default | FLOAT | 0.00-1000000–1000000 | — |
| ge | FLOAT | -1000000.00-1000000–1000000 | — |
| gt | FLOAT | -1000000.00-1000000–1000000 | — |
| le | FLOAT | 1000000.00-1000000–1000000 | — |
| lt | FLOAT | 1000000.00-1000000–1000000 | — |
| multiple_of | FLOAT | 0.000–1000000 | — |
| round_to | INT | 00–10 | — |
| value_inopt | FLOAT | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| value | FLOAT | — |