Hold

Hold exists for one job: keeping data alive between Loop executions. When the pack's Loop node re-runs a slice of your graph, every normal node starts from scratch - there's nowhere for "what did the last iteration produce?" to live. Hold is that place. It's the pack's own memory cell, and the README is explicit that a working Loop requires two Holds sandwiching it: one to save the previous pass's output, one to feed it back in.

It's also the node that makes things like FABRIC-style "pick an image, iterate on it" workflows possible, because a Hold can accumulate - not just store one value, but collect a list of values across iterations.

How it works

State lives in a HOLD_DB keyed by the node's id (and optionally a _key_id you set by hand), and it's tracked per prompt run, so a Hold from a previous queue doesn't leak stale data into your next one. The _mode enum decides what each execution does:

• save - append _data_in to the hold's stored list.
• clear - reset the held data (start a fresh accumulation).
• pin - hold a value steady; once pinned, subsequent executions keep serving it rather than overwriting.
• share - let other Holds with the same _key_id read this node's data. That's how you move values between the two halves of the Loop sandwich.

The optional _hold input is the HOLD_TYPE coming out of Loop; it's the signal that tells the Hold when to save vs. pass through. Feed _data_in whatever you want carried, and you get back _data_out (the current value) and _data_out_all (everything accumulated so far).

The inputs and outputs

• _mode - save / clear / pin / share, above.
• _key_id - an optional name to share storage across multiple Hold nodes.
• _data_in - the value to hold (any type).
• _hold - the loop signal from 0246.Loop.
• _data_out / _data_out_all - current value and full accumulated list, both output as lists.

How to install it

The usual:

cd ComfyUI/custom_nodes
git clone https://github.com/Trung0246/ComfyUI-0246

restart, or ComfyUI Manager → search "ComfyUI-0246". No models.

Common issues & troubleshooting

Values from a previous run show up unexpectedly. Hold state is scoped to a prompt run, but only if Loop/Hold agree on the run - if your Loop didn't execute (or you ran a subgraph in isolation), an old Hold can look like it's carrying ghosts. Use clear at the start of a loop body to reset deliberately.

_data_out_all is bigger than you expected. That's accumulation working as designed - Holds append across iterations. If you wanted just the latest value, read _data_out (or the last element of _data_out_all).

Hold without a Loop feeding _hold just passes data through - it stores, but nothing forces the save/read dance. Wire the loop signal properly or the memory never triggers. And the standing pack warning: single-author, dormant since early 2025, so validate the whole Loop/Hold stack against your ComfyUI version before you build a workflow around it.