EditableCLIPEncode

The category this node lives under says everything you need to know before reading further: promptcontrol/old. This is a holdover from an earlier iteration of Prompt Control, kept in the pack so workflows built with it don't break, not something to reach for in anything new. If you're starting fresh, this is the one node in this pack you should skip past.

What it does

Functionally it's an earlier take on what PCTextEncode does now - encode a prompt with Prompt Control's extra syntax on top of standard CLIP text encoding. It takes a clip and text, plus an optional filter_tags field that hints at the same tag-based prompt-filtering concept the pack's current Advanced nodes use for multi-pass workflows, and returns CONDITIONING.

If you have an existing workflow that already uses this node and it's working, there's no urgent reason to rip it out - it's kept around specifically for backward compatibility. But for anything new, PCTextEncode (no scheduling) or PCLazyTextEncode (with scheduling) is the current, maintained path, and it's what the rest of this pack's documentation and features are written around.

Inputs and outputs

Required: clip, text. Optional: filter_tags - a string field for filtering the prompt, the predecessor to the tags field on the current Advanced nodes. Output: CONDITIONING.

Installing it

It ships as part of the same single extension as every other node here - there's no separate install for it. ComfyUI Manager: search "ComfyUI Prompt Control", install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control

Where people get tripped up

The main trap is following an old tutorial or a shared workflow file that uses EditableCLIPEncode and assuming it's the node to build on going forward - it isn't. The pack's current README doesn't mention it at all among its core nodes; the documented, supported path for text encoding is PCTextEncode for a static prompt or PCLazyTextEncode for a scheduled one. If you inherit a workflow with this node in it, it should keep working, but the moment you're editing that workflow anyway, swapping it for PCTextEncode gets you onto the node that actually receives ongoing attention and matches the rest of the pack's features (weight-interpretation styles, BREAK/AND/CAT/AVG, IMASK() masking) without needing a separate filter_tags-style workaround.

This kind of /old category is a pattern worth recognizing across ComfyUI packs in general, not just this one: a v3.0.0 rewrite (this pack's parser moved to parsy for speed, per the README) is exactly the point where a maintainer keeps the previous node class registered under the hood - so old workflow JSON files still load and run - while steering all new documentation and effort toward the replacement. The node still works; it just isn't where the author's attention is, which means bug fixes, new syntax support, and anything else added going forward land in PCTextEncode, not here.

Practically, that gsc numbers on this page tell the same story: one impression, one click, which is about what you'd expect for a node that's essentially invisible in any current documentation and only turns up if you're specifically trying to understand an old workflow file someone handed you.