BISIDI Final Prompt Cleaner

If you've ever wired a "thinking" Qwen-VL straight into a CLIPTextEncode, you know the pain: half of what lands in conditioning is the model narrating its own reasoning out loud ("let's analyze this viewport… first, I should check the geometry…") before it gets around to the actual edit. The BISIDI Final Prompt Cleaner is a tiny text-munging node that sits between the VLM and your conditioning and cuts all of that out.

It was built for BISIDI's CAD/BIM screenshot-to-render pipeline - you feed a Qwen Thinking VLM a viewport screenshot, it outputs an edit instruction, and this node makes sure only the instruction survives. But the job is generic. Any workflow where a VLM returns reasoning text before the final prompt has the same leak, and the node handles it.

How it works

The source is one file, a hundred-ish lines of Python re, no dependencies. Nothing clever, which is why it's trustworthy. In order of preference it:

1. Finds <FINAL_PROMPT>...</FINAL_PROMPT> in the raw text and extracts just that block - Qwen is instructed to emit its answer inside that tag.
2. Failing that, deletes <think> blocks and everything after the closing </think>, then strips leftover tags.
3. Keeps hunting for "edit the provided…" or, last resort, scans paragraphs from the bottom up, rejecting anything that smells like planning ("got it", "wait,", "the user wants") and anything under 12 words.

Then a validation pass: if the candidate is empty, shorter than 12 words, still looks like reasoning, or contains none of the render-family words (render, photorealistic, architectural…), the whole thing is discarded and the fallback_prompt is used instead. And because this pack is opinionated about its own domain, surviving text gets normalized - duplicate "edit the provided…" prefixes collapsed, and if no render intent is present it prepends the canonical Edit the provided CAD/BIM viewport screenshot into line. It also hard-trims at 110 words.

The inputs that matter

There are only two, and a beginner sets both:

• text - the raw VLM output. It's forceInput, so you wire the VLM's string output straight in; you can't just type into it.
• fallback_prompt - what gets used when extraction is unsafe. The default is empty, and an empty fallback means an empty FINAL_PROMPT output, which will silently poison your conditioning. Set this to a safe production prompt. It's the single most important thing to touch.

The one output is FINAL_PROMPT (a STRING), which you feed into ShowText to eyeball, then on to CLIPTextEncode.

The recommended chain from the README: Qwen Thinking VLM → ShowText → AILab_BISIDI_FinalPromptCleaner → ShowText → CLIPTextEncode. The extra ShowText is worth keeping so you can see what the cleaner actually let through before it gets encoded.

Install

Pure stdlib, no model files, no API keys, no network calls - the safest kind of custom node to install. Through ComfyUI Manager, search "ComfyUI-BISIDI-FinalPromptCleaner" and install. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/sibidicto/ComfyUI-BISIDI-FinalPromptCleaner.git

Restart ComfyUI and the node appears under AILab/QwenVL as "BISIDI Final Prompt Cleaner".

Where people get burned

Three real traps, all visible in the source. First, the render-intent enforcement is CAD/BIM-specific: if your candidate doesn't contain a render word, the node rewrites it into "Edit the provided CAD/BIM viewport screenshot into a professional architectural render with…". Great for the pack's home turf, actively wrong for a general-use prompt - that boilerplate will bleed into your generation. Second, the 12-word minimum rejects short prompts you might have been happy with, bouncing them to the fallback. Third, the 110-word cap silently lops the tail off long, detailed prompts.

None of it is broken; it's a domain-tuned utility. Feed it a thinking VLM's CAD-render prompt and it's exactly the node you'd want. Feed it arbitrary creative prompts and it'll fight you. Set a real fallback, keep a ShowText in the chain, and let it do its one job.