IAMCCS_Ltx2HelperModules Runtime Bridge

This node doesn't generate pixels, and it doesn't sample. It's a contract node for the IAMCCS SuperNode system - the pack's wrapper layer that compresses whole LTX-2 pipeline stages into single boxes so a long audio+image→video workflow doesn't degenerate into node spaghetti. If you've only met the regular IAMCCS LTX-2 nodes (bridges, samplers, LoRA stacks), this is the layer above them: it collects the planning and routing decisions from across the graph and emits a structured payload that a SuperNode's backend consumes.

The author's own framing from the release thread is the best summary: LTX 2.3 workflows "turn into node spaghetti… frame math everywhere, VAE logic split across half the graph, one wrong value and everything breaks three segments later." The Helper Modules exist to make that manageable, and the RuntimeBridge is the piece that decides how the whole run should behave.

How it works

You feed it JSON payloads as strings - planner_payload, audio_payload, and optionally continuity_payload, keyframe_payload, refresh_payload - plus two routing enums:

• runtime_profile - native_canvas (default), disk_low_ram, or image_batch. This is the memory strategy: run it in the normal graph, spill frames to disk for low RAM, or work on image batches.
• model_binding - external_canvas (default), ltx_runtime, or custom. Where the model/backend comes from.

It parses the payloads, resolves the effective profile (a goal1_preset inside the planner payload can override your enum choice), and builds a backend_payload JSON describing the run: pipeline kind, segment index/count, continue-generation flag, whether continuity/keyframe/refresh payloads are present, and a prompt_summary. That payload is then wrapped into a contract (the IAMCCS_SUPERNODE_CONTRACT type) and threaded into a linx (the IAMCCS_SUPERNODE_LINX type) - the two link types SuperNodes use to chain. A report string summarizes the resolved config.

The optional parent_contract / linx inputs let it extend an existing chain instead of starting one.

Inputs and outputs

• Required: planner_payload, audio_payload, runtime_profile, model_binding, prompt_summary.
• Optional: parent_contract, linx, continuity_payload, keyframe_payload, refresh_payload.

Outputs: backend_payload (STRING), contract, linx, report.

Install

ComfyUI Manager → "IAMCCS", or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

Restart. No model downloads - the payloads it reads come from the planner/audio nodes in the same pack.

Gotchas

The biggest confusion is scope: this node is metadata plumbing for the SuperNode / helper-modules workflows, and it's near-useless standing alone. If you aren't building one of the pack's audio+image→video SuperNode graphs, skip it - the plain extension nodes are what you want. When you are inside that ecosystem, the report string is your diagnostics: it prints the effective goal1_preset, segment, runtime profile, and whether continuation is on, so a run that comes out "wrong" usually shows the bad decision here first. And the payload JSONs are contract-shaped - the author has said these workflows are moving targets (there's a Patreon requirements doc for the SuperNodes), so expect field names to shift between pack versions.