Context Enter

Some nodes - SAM3 segmentation is the poster child - expose a should_unload input that decides whether the model stays resident in VRAM after it runs. XJContextEnter is the node that says "keep it loaded, we're just getting started." It's a passthrough with two constant boolean outputs, and its entire purpose is to make model residency explicit in your graph.

You almost never want one of these; you want a pair. This is the enter half, and the same pack ships XJContextExit as the exit half. Together they bracket a stretch of your workflow into a "context": keep the model loaded through the middle, then release it at the end. The pattern from the node's own description: connect ContextEnter's FALSE output to SAM3's should_unload (meaning don't unload), process a bunch of items so the model stays warm in VRAM, then connect ContextExit's TRUE output to the last should_unload so it finally releases.

How it works

There's no computation here at all, and that's the design. XJContextEnter takes an optional value of any type, passes it through unchanged, and emits two boolean outputs: FALSE and TRUE. The naming is the whole trick - the enter semantics attach to the FALSE output, because "false" on should_unload means "keep the resources." TRUE is provided too, for anyone who just needs a true constant mid-graph.

Because the value input is optional and typed as * (any type), the node can sit harmlessly in a data path without forking it - your image or conditioning flows through while the booleans ride along. Nothing is stored, modified, or validated; it's a constant generator wearing a routing costume.

The inputs and outputs

• value (optional, any type) - passed through. Can be left unconnected if you only need the booleans.
• Outputs: passthrough (any type), FALSE (Boolean), TRUE (Boolean).

Installing it

It's part of ComfyUI-XJNodes:

cd ComfyUI/custom_nodes
git clone https://github.com/alexjx/ComfyUI-XJNodes

then restart ComfyUI (or ComfyUI Manager → ComfyUI-XJNodes). No models, no dependencies - it's a one-function node.

Common issues

The classic mistake is wiring it backwards: hooking TRUE to should_unload at the start of a context, which unloads the model the moment you wanted it resident, and the next item eats a reload. Decide which semantic you want and be consistent - that's genuinely the entire failure mode for this node. If you're not sure you need it, you probably don't: it earns its keep only in multi-pass workflows where model loading dominates the runtime, and it does absolutely nothing outside that situation.