Continuity Job

First, the honest answer to the question you actually googled: you do not add this node. It's marked is_dev_only in the pack's source, so ComfyUI hides it from node search entirely, and nothing about it is meant for a canvas. But if you've used the ComfyUI-Continuity pack - the "one node" that drives MiniMax H3, LTX 2.5, Krea 2, Ideogram 4.0, Qwen Image Edit and Flux 2 Klein from a single prompt, all local open weights, no API key - then you've been running this node every single time. It's the engine room behind every Render, Refine and Bench press the pack's buttons make.

What it actually does

ContinuityJob exists because ComfyUI's queue only runs prompts, and the pack's buttons want to put work on that queue. So when you press Render, the pack's server code builds a one-node "workflow" behind the scenes, something like this:

prompt = {"1": {"class_type": "ContinuityJob",
                "inputs": {"job": json.dumps({"kind": "render", "body": ...})}}}

That gets validated the same way a normal render is, then dropped onto ComfyUI's prompt_queue. When the node runs, execute reads the job JSON, looks up which function handles that kind in a simple table, runs it, and hands the GPU back. It returns nothing to a graph - no wires, no outputs, nothing upstream. As the author's own docstring puts it: "the only reason it is a node at all is that a node is what the queue takes."

Why the author bothered - this is the interesting part

This didn't used to be the design, and the change is a genuinely good story. Earlier versions ran the pack's jobs in a separate thread pool beside ComfyUI's worker, so a trace, an upscale, a refine and a render could all be on one GPU at once, stomping on each other. Worse, the progress bar lied: a shared global kept a phantom "Sampling" card alive for a render that had already stopped, and refreshing the browser didn't fix it because the stale state lived in the server.

Pushing the work through the real queue fixes all of that. Cancel now cancels these jobs like any other. The progress bar is the real one. queue_remaining counts the pack's jobs, so one button can speak for everything pending. It's also a nice pattern to steal if you ever write your own custom node that does server-side work: use a hidden output node as a queue entry.

The inputs and outputs (all two of them)

• job - the only input: a multiline string containing a JSON blob {"kind": ..., "body": ...}. Never write this by hand; the frontend builds it, and the body is deliberately nested so a refine's own kind field can't collide with the envelope's. Default is "{}".
• Outputs - none. It's an output node that writes a file or a rewritten prompt and reports back to the frontend under its own ui.continuity key.

One detail worth knowing: the node always reports a fresh fingerprint, so the execution cache never short-circuits a second button press. Two presses of Trace with identical dials are two tracings - the second one writes clip-edges-2.png. If that trick weren't there, the button would silently stop working the second time you used it.

Install and models

Same for the whole pack. ComfyUI Manager → search "Continuity" (the repo renamed from ComfyUI-MiniMax-Creator, so the folder may differ), or:

cd ComfyUI/custom_nodes
git clone https://github.com/roadmaus/ComfyUI-Continuity

Restart ComfyUI. There's nothing to pip install - the pack's pyproject.toml lists zero dependencies, which is refreshingly rare. The real download burden is the models, and it's not small: the flagship is MiniMax H3, a 33B omni-modal model with native audio that wants serious VRAM, and the others are multi-GB checkpoints too. The README's model list tells you each file and the exact folder it goes in. And one genuinely annoying catch the pack inherits: H3's community license geofences out the US, EU, UK and South Korea, so "local and free" is qualified for a lot of users.

If you've come this far because a saved workflow references ContinuityJob and something's red: the node id is frozen by design (a rename would strand any in-flight job across a restart), so a validation failure means the pack's frontend and server disagree about a job's shape - a pack bug, not your workflow. Reinstall the pack and move on.