CMK Boundary Cache

CMK Flow's FaceProcess module is a self-contained face pipeline - detect, restore or re-detail, paste back - and CMK Boundary Cache is the wall around it. Three inputs in (MODEL, IMAGE, LOG), the same three out, and a cache behind the wall that can end the run before any of the expensive machinery starts.

What it is

A CMK/Developer/Boundary & Cache node, which in CMK terms means developer plumbing: it's already inside the pack's face workflows, and you'll meet it when you open one, not when you build one from scratch. Yes, it shares a display name with two siblings - the detailer boundary and the FaceRebuild boundary - and yes, that's confusing. They're separate classes with separate caches; this one is scoped to faceprocess_boundary.

How it works

All three inputs are lazy, which is the whole mechanism. ComfyUI asks check_lazy_status before evaluating anything upstream, and this node can answer "I don't need anything" - an empty list. When it does, the entire upstream face chain is skipped, not evaluated and thrown away.

It decides that from two things it reads out of the prompt graph. First, a fingerprint of the boundary node itself plus a schema version (cmk_faceprocess_boundary_v5), with MODEL, IMAGE and LOG excluded from the hash on purpose - those are the payloads, not the settings. Second, a dependency manifest collected from the upstream FaceProcess branches, keyed on the branch spec for CMKFaceProcessPipe with its own revision scheme. A cache hit is only accepted if that manifest still matches the branch revisions currently materialised. Edit a branch and the boundary recomputes; leave its siblings alone and they still resolve from cache.

There's a second, cheaper path: before touching the cache it does a deliberately shallow, linear inspection of the graph to see whether the FaceProcess module is statically disabled - it reads the enable booleans off the prepare and execute nodes and nothing else, never fingerprinting the expanded upstream. If the module is off, the boundary declares DISABLED_PASSTHROUGH_READY and passes the three inputs through. That's why disabling the face module in CMK is genuinely free rather than merely skipped.

Status goes to ComfyUI/temp/cmk/faceprocess_boundary/last_status.json - MISS, STORED, HIT_READY, DISABLED_PASSTHROUGH_READY. If you're wondering whether a fast run was a cache hit or just a small image, that file will tell you.

Why the boundary matters at all

Face restoration and face re-detailing are the two most expensive optional passes in a typical SDXL workflow: InsightFace runs a detection and alignment pass per image, then a restore network runs per face, and the detailer variant does a full VAE encode/sample/decode per region on top. In a modular pipeline with parallel face branches - one restoring, one re-detailing - everything upstream of the merge gets re-run for every tweak if there's no boundary. This is the node that makes the second run cheap.

The honest caveat is the same as every cache in this pack: it lives in ComfyUI/temp/cmk/, so a restart empties it. First run after a restart is expected to be MISS → STORED. It's a speed-up inside a session, not a persistent artifact, and the manual is explicit that caches are not a portable project format.

Install

It ships with the pack. Manager: search CMK Flow, install the CMKFlow entry, restart. Manually, from the directory holding main.py:

git clone https://github.com/CMKFlow/cmk_nodes.git custom_nodes/cmk_nodes
python3 custom_nodes/cmk_nodes/scripts/install_cmk_requirements.py

Wait for CMK dependency check: OK. If your face module does restoration rather than re-detailing, the pieces you actually need are model files, not node packs: InsightFace's buffalo_l pack, and restore models (GFPGAN or CodeFormer) under models/facerestore_models. The resource checker audits those specific filenames and can fetch them:

python3 custom_nodes/cmk_nodes/scripts/check_cmk_resources.py --models-root "/path/to/shared/models"

Worth repeating because it bites people: insightface is a hard dependency of this pack (it's in requirements.txt), and its pretrained ONNX models are not MIT - the library is, the weights aren't, which matters if you're selling output. If all you needed was to find and crop faces, a MediaPipe-based detector would be licence-clean; if you're restoring or swapping identities you're stuck with the InsightFace path either way.

Issues worth knowing

Don't treat the boundary as a save point. Anything downstream that reads its outputs is reading a cache entry keyed to a graph revision; change the graph and the answer changes.

If a branch that should be cached keeps re-running, the likely cause is the dependency manifest moving - a revision bump on one branch invalidates the whole boundary for that key. And after a pack update, expect one full recompute, because the schema version is part of the fingerprint. That's by design: it's how the pack avoids serving you a stale result from a different code path.