CMK Model Forward -Pipe-

Some nodes exist to solve a problem you didn't know the graph engine had. This is one of them. It takes a CMK_MODEL_PIPE and gives the same CMK_MODEL_PIPE back. No loading, no mutation, no side effects. Its entire source is fifteen lines.

The docstring says it plainly: it exists "solely to expose the incoming MODEL resource pipe at a subgraph output without routing it through a Prepare or Execute node."

Why that's a real job

ComfyUI subgraphs - and CMK ships a lot of them - hide their internals. To get a value out of a subgraph, something inside it has to publish that value on a subgraph output socket. Normally that means a node's output, so you'd have to build a chain of nodes just to carry the MODEL from the boundary to the exit.

Worse, the obvious workaround is to route MODEL through a Prepare or Execute node that happens to have a MODEL output. That works right up until those nodes do something to the model on the way through, or until you need a MODEL-shaped output that doesn't depend on a specific module's params.

CMK Model Forward -Pipe- is the escape hatch: a pure pass-through that exists so the pack's subgraph authors can publish MODEL at the boundary without inventing a fake module.

It also fits a stated architectural rule in CMK: modules must not mutate MODEL. This node is the tool that makes that rule cheap to obey.

Inputs and outputs

There is one required input, MODEL (CMK_MODEL_PIPE), and one output, also named MODEL (CMK_MODEL_PIPE). No widgets, no optional sockets, nothing to configure.

The implementation does two checks before returning:

None → raises "CMK Model Forward -Pipe-: MODEL is missing"
Not a dict → raises a type error naming what you actually passed

That second check matters more than it looks. CMK_MODEL_PIPE is a dict at runtime, and ComfyUI's sockets are type-checked at the graph level, not the value level. If some other node's pipe leaks onto this wire - a visual pipe, a process pipe, an Impact Pack BASIC_PIPE tuple - the graph will happily let you connect it if types line up loosely, and this node is one of the few places that will tell you loudly.

Where you'd use it

Three realistic cases:

Publishing model state out of a subgraph. You're building a reusable subgraph and want the caller to be able to reach the model pipe without re-loading.
Forking a model to two consumers with a readable graph. One output can only go one place in a tidy layout; a forward node gives you a clean named tap.
Making an implicit dependency explicit. If a downstream module takes MODEL from far upstream, routing it through a forward node at the boundary documents that the model crosses this line.

If you're hand-building a plain graph and none of those apply, you don't need it. Reaching for this on a small workflow is a sign you're over-abstracting.

Install

Part of CMKFlow/cmk_nodes. ComfyUI Manager → search CMK Flow → install the CMKFlow entry → restart ComfyUI. Manual:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

CMK dependency check: OK is the finish line. This particular node has no model or third-party requirements of its own; the heavy requirements.txt list - ultralytics, insightface, segment-anything, onnxruntime, nudenet - exists for the detection, face and video side of the pack.

Two things to know

It's a Developer-category node. CMK/Developer/Pipe/Forward. It'll show up in the node menu under that namespace, and it will look like clutter if you're not building subgraphs. That's fine - ignore it.

Node names and display titles diverge in this pack. The README is explicit that visible titles are for presentation while "technical identity and navigation rest on metadata, node classes, provider keys and UUIDs." So if a workflow's title on a node doesn't match the class you searched for, that's the design, not a stale install. Search by class name when in doubt.

Restart after installing, not before. This one is trivial enough to look broken if the pack half-loaded - a missing node in a shipped workflow usually means the dependency script never ran, not that the node is broken.