IAMCCS_H3CharacterSwapModelR49

You've built an H3 face-swap workflow. Swapped shots need a model with the character LoRA fused in; everything else in the same sequence needs the plain base model. Without a node like this you either duplicate the entire downstream graph or you rewire twenty links every time the sequence changes.

IAMCCS_H3CharacterSwapModelR49 exists so you don't. It's a two-in, one-out switch: hand it both models, and it decides which one goes downstream based on what the current shot is actually doing.

What it is

One required input, cine_linx, which is the IAMCCS bus (their IAMCCS_SUPERNODE_LINX type). Everything in this pack is organised around that: the Shotboard and Settings PRO write a "shotplan" into the bus, and downstream nodes read it instead of making you wire every setting by hand.

Two optional model inputs: base_model and swap_model. One output, model, which you wire into your H3 conditioning/sampler chain exactly as you would any MODEL.

No knobs, no dropdown. The choice isn't yours at this node - it's in the plan. That's the whole design, and it's the bit that surprises people.

How it works

Both model inputs are declared lazy, and the node implements check_lazy_status. In plain terms: ComfyUI asks the node which inputs it actually needs before it evaluates anything, and this node answers with exactly one name. If the shotplan's task mode is the LoRA/character-swap mode, it asks for swap_model and never for base_model.

That matters for memory, not just tidiness. Two H3-scale model stacks resident at once is the difference between a queue that runs and a queue that swaps to system RAM and crawls. Lazy inputs are how a single graph keeps both options live without paying for both.

If you've read anything about ComfyUI's execution model, this is the same machinery that keeps optional branches from firing - the engine walks backwards from output nodes and only executes what's reachable. Lazy inputs tighten that: a reachable-but-unneeded input still doesn't get evaluated. It's a cheap trick with an outsized effect on big graphs, which is why half the interesting nodes in this pack lean on it.

What you actually set

Nothing. That's the honest answer. Your only real decision is upstream, in the H3 Settings PRO surface: whether the current shot's task mode is the swap mode or a normal generation mode.

The one thing worth internalising: this node is a router, not a merger. It does not stack the LoRA for you, and it doesn't blend two models. swap_model needs to already be the model with the swap LoRA applied - the pack's own 1.5.8 notes say character swap and VFX require their matching H3 LoRAs, and this node assumes you've loaded them upstream.

Install

Same as the rest of the pack - this ships inside IAMCCS-nodes, not as a standalone package.

Easiest path is ComfyUI Manager: search IAMCCS Nodes, install, restart, hard-refresh the browser. Manually:

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

Then restart ComfyUI. The pack's own README is explicit that it should exist only once in custom_nodes - a duplicate copy is a common cause of nodes loading with old definitions or the frontend panel routes going stale, and that failure looks like "my new node isn't there" rather than anything obvious.

There's no requirements.txt in the repo, so there's no pip step for the pack itself. What you do need is the model side: H3 weights, VAE, text encoder, plus the character/swap LoRA. ComfyUI 3.0.0 or newer per the pack's pyproject.toml. Nothing models-wise ships with the pack at all.

Where people get burned

The selector returns base when you expected swap. Nine times out of ten the shotplan isn't in swap mode - the node is faithfully reporting the plan. Check the Settings PRO task mode for the shot you're queueing, not the graph you're looking at.

You wired the same model to both inputs. It works, and it's a no-op, and then you spend an hour wondering why the swap isn't happening. The LoRA has to be in the model you feed swap_model.

You dropped the node into a bare graph. With no real cine_linx upstream, there's no shotplan, and there's no mode to route on. This family of nodes is designed to sit downstream of the H3 Shotboard/Settings PRO pair, not to be the entry point.

Leftover duplicates in custom_nodes. If the node shows up twice in the search palette or behaves like an older version, that's the duplicate-copy problem from the README, not a bug in the node.

Related nodes

IAMCCS_H3FaceSwapInput is the sibling in the same module and handles the tracked-crop side of a subject swap; the H3 Settings PRO panel is where the engine variables (native single pass vs the optional detail pass) live. If you only remember one thing: this node is the plumbing that lets one graph carry two model stacks, and it earns its place by not loading the one you aren't using.