Cube Input

This node does one thing, and it's not the thing the name suggests. Cube Input doesn't transform your data, resize anything, or touch a pixel. It passes value straight through and spends its real energy on bookkeeping. Its job is to mark the front door of a SugarCube: a reusable slice of a ComfyUI graph that SugarCubes saves as a .cube file with a stable public surface.

If you've never heard of SugarCubes, the framing is this. The same author behind the Sugar project - which writes ComfyUI workflows as readable text - built SugarCubes so you can carve a section of your graph, declare its boundary, and save it as a reusable unit that Sugar scripts can compile against and that you can drop into any workflow "like Legos," as the author put it. A workflow built from dozens of branching switches and booleans turns into a few chained segments, each with one wire in and one wire out. That's the design sweet spot: cubes are best when they're simple, even if nothing stops you from giving them many ports. ComfyUI's native Subgraph can collapse a region the same way, and the author is candid that subgraphs are close - the difference is the .cube format: named inputs, named outputs, authored defaults, versioned identity, and Git-backed packs you can share.

How it works

Cube Input is a marker node, and it's genuinely inert. The class docstring says it "marks the start of a SugarCube subgraph." Its input type is * (ANY) and so is its output, so it will accept anything you throw at it - a model, a latent, a string, a conditioning. The forward() method validates two of its widget fields and then returns (value,) untouched. It also declares a GRAPH_PASSTHROUGH_OUTPUTS entry, which tells ComfyUI the output is literally the same value as the input for provenance and caching purposes. Nothing about it affects what comes out; it exists so SugarCubes' exporter can find your cube, group its markers by cube_id, and build the cube's public API from the aliases.

The inputs that matter

Five fields, and only one of them is a real footgun:

• value - the actual data. Wire your model/latent/image into this.
• default_alias - the public name of this input in the cube's surface. Required. Leave it empty and the node throws a ValueError the moment SugarCubes tries to export.
• cube_id - which cube this marker belongs to. Optional at runtime, but the exporter refuses to group a marker without it, so set it before saving.
• instance_alias / instance_id - let you tell two placements of the same cube apart (e.g. "upscale pass" vs "refine pass"). Leave them blank unless you're doing multiple instances.

Installing it

Through ComfyUI Manager, like anything else: open the Custom Nodes Manager, search for SugarCubes, hit Install, restart. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/Artificial-Sweetener/SugarCubes

Then restart ComfyUI. No model downloads, no heavy Python deps - the pyproject.toml lists only aiohttp. The one thing to check before you install: it declares Python >= 3.12, so if your ComfyUI venv is on 3.10 or 3.11, this pack won't import until you move up.

Where people trip

The usual first stumble is leaving default_alias empty and then wondering why the cube export fails with a "missing default_alias" error - it's the one field the node actually enforces. The second is expecting these markers to do something in a plain workflow. They don't. Outside SugarCubes' exporter and the Sugar toolchain, Cube Input is a transparent wire with three text boxes on it, which is the whole point. And remember it's a passthrough: if you put a marker in the middle of your graph and see no data on the other side, the problem is upstream of the marker, not in it.