Apply Ideogram4 Phase C V2 Strength

This is the payoff node. Gen2_LoadIdeogram4PhaseCV2Router just reads files; this one takes your Ideogram4 MODEL, your CONDITIONING, and the router bundle, and converts a plain LoRA from "one strength everywhere" into per-group, per-timestep, per-content gated residuals - "content-, timestep-, and group-gated residuals," in the author's own description.

Why you'd bother: a normal LoRA is a fixed weight applied at full blast through every denoising step, whether the subject in your prompt is present or not. That's exactly why a character LoRA at 1.0 leaks style onto things that aren't the character, and why people constantly sit at 0.6–0.8. Phase C V2's idea is that a small router network reads the conditioning and the current timestep and decides, group by group, how hard to push. The LoRA gets to be selective. It's fiddly, it's bleeding-edge, and for the exact-artifact setup it's intended for it's genuinely clever.

How it works

The mechanism, grounded in the source. The node first validates everything, fail-closed style:

• The MODEL must be a native Ideogram4 diffusion model - Flux, Klein, or Qwen gets a hard error.
• The CONDITIONING must carry Phase C V2 activator state, which only comes from Gen2_Ideogram4V9TriggerTextEncode in semantic_only mode with exactly three literal occurrences of the trigger (that's 12 expanded slots: 3 occurrences × 4 virtual tokens). Use a different encoder or count and the node refuses to run.
• The router's expected hashes must match the embedding and TE-adapter artifacts that produced your conditioning.

Then it clones the MODEL and walks its patch table looking for the exact V3 LoRA adapters the registry describes - it checks shapes and fp32 norms of the up/down matrices, and requires the LoRA multiplier to be 1.0. Any mismatch and you get "MODEL does not contain the exact Phase C V3 registry." The node won't gate a random LoRA - it gates the LoRA the router was trained with, at full registered strength.

The runtime is installed on the clone via ComfyUI's PatcherInjection - no core files edited, consistent with the pack's philosophy, and it survives git pull. At each sampling step a wrapper runs the router: it projects the activator states through the model's own llm_cond_norm/llm_cond_proj, encodes a compact "activator code," and gets back per-group scores q conditioned on the normalized timestep. Those scores become gates in [0,1], and each LoRA residual is scaled by its group's gate. Conditioned residuals per step, done.

The one knob that matters

style_strength (FLOAT, 0–1, default 0.5). Here's the part that trips everyone up:

• 0.5 is identity, not "half." At exactly 0.5 every gate is 1.0 - the LoRA applied exactly as trained, no gating at all. This is the "native" position.
• Below 0.5 uniformly fades the whole LoRA - 0.25 behaves like a 0.5 LoRA weight, 0 is off. Same as a regular strength dial, just with the router in the loop.
• Above 0.5 is where the magic (and risk) lives: the router boosts the groups it favors above 1.0 and suppresses the ones it doesn't. Start around 0.6–0.8 and watch for over-amplification.

debug_logging (BOOLEAN, default off) is the other input worth touching. Turn it on and the console prints tau, style_strength, and gate min/max per step - genuinely the fastest way to see whether your gates are doing anything at all.

Outputs: a patched model (MODEL) and the conditioning (CONDITIONING), which passes through unchanged. Wire the model into your sampler's model input, and the conditioning into its positive input, exactly as you would with any patched model.

The workflow it belongs to

Load Ideogram4 → Gen2_Ideogram4AITKLoRALoader applies your V3 LoRA at 1.0 → V9 trigger path builds the CONDITIONING (semantic_only, three literals) → Gen2_LoadIdeogram4PhaseCV2Router → this node → sampler.

Installing and gotchas

Same pack as everything else here: Manager search ComfyUI-gen2, or clone + pip install -r requirements.txt, on ComfyUI v0.28.0+. No extra deps and no bundled model files.

Where people actually get burned: (1) the conditioning-state error - wrong text encoder or occurrence count; (2) the registry error - wrong LoRA, or it's not at strength 1.0; (3) hash mismatches across router, embedding, and TE adapter - the whole chain is welded together and anything from a different training run is rejected on purpose. And be honest about the niche: these nodes aren't in the pack README yet, there's no community footprint, and the router artifacts aren't shipped - you need a matching trained set. If you don't have that, it fails closed and tells you. When you do, it's the most controllable LoRA application in the pack.