Custom Token Processor
Routing Prompt Fragments with a Custom Token
- processed_source
- processed_target
Most of the time one prompt in, one prompt out is all you need. But there's a class of ComfyUI workflow where you want part of a prompt to go somewhere else entirely - the README's example is two samplers each using a different model, where the subject line goes to one and the style tail goes to the other. You could hand-maintain two separate prompt boxes, but then the wildcard randomization in the shared section drifts out of sync.
Custom Token Processor is the general version of its sibling's trick. Where the Negative Wildcard Processor hardcodes <! !> as its marker, this node lets you pick the delimiter - so you can route fragments by token to whatever destination you like.
How it works
Give it a token, and it looks for text wrapped as <token ... token> - the token appears twice, once to open and once to close. With token zyup, the pattern is <zyup(.*?)zyup>, so this:
a young woman, <zyup film grain, kodak portra zyup>, golden hour
...becomes "a young woman, , golden hour" in the source and "film grain, kodak portra" gets appended to the target. Mechanically it's the same two-string pass as the negative processor: find all matches, strip them from the source, append to the target. And like its sibling, it's pure Python stdlib - no dependencies, no models, nothing to fight your environment over.
Note what it doesn't do, so you don't assume symmetry with its sibling: it won't strip <lora ...> tags. That's specific to the negative processor. Here the token is your only control.
The inputs that matter
Three inputs, all STRING:
- token - your chosen delimiter, single-line. The README suggests
zyup. Pick something distinctive that won't appear naturally in your prompt. - source - the main prompt the fragments get pulled out of.
- target - where the extracted bits go.
Outputs are processed_source and processed_target, both strings, each wiring into its own CLIP Text Encode. In the two-sampler workflow, source feeds the first encoder and target feeds the second - same prompt text, different route.
Install
Same pack, same zero-fuss install. Via ComfyUI Manager, search "Negative Wildcard Processor" (the pack's title) or clone:
cd ComfyUI/custom_nodes
git clone https://github.com/GrvBdgr/comfyui-negativewildcardsprocessor
Restart, and you'll find it under Dynamic Prompts. No requirements.txt, no model downloads.
The trap: silent failure
This node fails quietly. Forgetting to close the token - writing <zyup stuff with no trailing zyup> - doesn't error; the regex just doesn't match, the fragment stays put in the source, and your two encoders get identical text. You'll stare at two samplers producing the same image wondering what broke. So: when the split "isn't working," check that both zyup markers are present first.
Second gotcha, worth knowing if you get clever: your token is dropped into the regex verbatim, no escaping. Stick to plain alphanumerics and you'll never hit it, but a token like [x] is regex soup waiting to happen.
For the niche it's built for - one prompt, multiple conditioning routes - it's the tidy answer, and at zero dependency cost it's cheap to keep around just in case.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| token | STRING | — | |
| source | STRING | — | |
| target | STRING | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| processed_source | STRING | — |
| processed_target | STRING | — |