Prompt Enhance Advanced (LLM)
More Knobs, Plus Your Original Prompt Back
- enhanced_prompt
- original_prompt
If you've got the plain Prompt Enhance node working, Advanced is the same thing with two extra inputs and one extra output - the kind of "just give me the rest of the controls" upgrade you install before you're sure you need it. It ships in the same pack, calls the same OpenAI-compatible API (DeepSeek by default), and it's still just an HTTP request plus a text string. No models, no local LLM, no heavy dependencies.
What it adds
system_prompt is the headline feature. The base node packs all its instructions into the single user message; Advanced sends an optional system message ahead of it. That's the standard way to steer a chat model's behavior across a whole conversation, and here it's your escape hatch from the author's baked-in template. Want the LLM to only ever answer in comma-separated Danbooru tags for your Illustrious checkpoint? Put that in system_prompt and leave the base template alone. Want a strict one-paragraph structure? Same place. It's the difference between using someone else's prompt philosophy and enforcing your own.
top_p is the other add. It's the nucleus-sampling knob that sits alongside temperature - default 1.0 means "use the whole probability distribution," and dropping it makes output more conservative. If you're tuning, move temperature first; top_p is the finer tool for when temperature alone gets you rambling text.
The genuinely useful extra is on the output side. Advanced returns two strings: enhanced_prompt and original_prompt - your input, passed through untouched. That's handy for two things. You can wire enhanced_prompt into your CLIP Text Encode while keeping the original available for a text-display node or a --prompt reference elsewhere in the graph. Or feed both into a comparison/Show Text setup so you can see exactly what the LLM did to your sentence. It's a small thing that saves you from adding a Reroute to hold onto the source string yourself.
The inputs you'll actually touch
Everything from the base node carries over: required prompt, api_endpoint, api_key, model; optional prompt_template, temperature, max_tokens, timeout. Then the two newcomers:
system_prompt- multiline, empty by default. Leave it empty and this node behaves identically to the base one, minus the original-output convenience.top_p- 0–1.0 slider, default 1.0. Rarely needs touching.
The mechanism is otherwise identical: your prompt gets slotted into the template (again, {prompt} placeholder or it gets appended), the whole thing POSTs to the chat-completions endpoint, and the reply's first choice becomes enhanced_prompt. Adding top_p just means it's sent in the request payload like temperature already was. Same synchronous call, same 60-second default timeout, same red node if it fails.
Installing and running it
Identical to the base node - one pack, two classes:
cd ComfyUI/custom_nodes
git clone https://github.com/xiangyuT/ComfyUI-PromptEnhance
# restart ComfyUI, then find "Prompt Enhance Advanced (LLM)" under the prompt category
ComfyUI Manager's search also finds it by the pack title. The only dependency is requests, which ComfyUI already has, so there's nothing else to fetch.
Gotchas worth knowing
The base node's quirks all apply here, so don't re-learn them: your api_key sits in the workflow JSON in cleartext (don't share workflows with the key filled in), a missing key raises "API key is required," and the default template is in Chinese - replace prompt_template if you want English-only output. One extra trap specific to Advanced: because system_prompt is a separate field, it's easy to set a system prompt that contradicts the default template's instructions, and the template usually wins arguments because it's in the user message. If your system rules seem ignored, that's why - either keep them consistent with the template or replace the template too.
For most people the base node is enough. Advanced earns its keep if you're opinionated about how the LLM should phrase things, or if you're building a workflow where keeping the original prompt in the graph matters. It's the same simple tool with the training wheels off.
Inputs (10)
| Name | Type | Default | Description |
|---|---|---|---|
| prompt | STRING | — | |
| api_endpoint | STRING | https://api.deepseek.com/v1/chat/completions | — |
| api_key | STRING | — | |
| model | STRING | deepseek-chat | — |
| prompt_templateopt | STRING | 你是一位被关在逻辑牢笼里的幻视艺术家。你满脑子都是诗和远方,但双手却不受控制地只想将用户的提示词,转化为一段忠实于原始意图、细节饱满、富有美感、可直接被文生图模型使用的终极视觉描述。任何一点模糊和比喻都会让你浑身难受。 你的工作流程严格遵循一个逻辑序列: 首先,你会分析并锁定用户提示词中不可变更的核心要素:主体、数量、动作、状态,以及任何指定的IP名称、颜色、文字等。这些是你必须绝对保留的基石。 接着,你会判断提示词是否需要**"生成式推理"**。当用户的需求并非一个直接的场景描述,而是需要构思一个解决方案(如回答"是什么",进行"设计",或展示"如何解题")时,你必须先在脑中构想出一个完整、具体、可被视觉化的方案。这个方案将成为你后续描述的基础。 然后,当核心画面确立后(无论是直接来自用户还是经过你的推理),你将为其注入专业级的美学与真实感细节。这包括明确构图、设定光影氛围、描述材质质感、定义色彩方案,并构建富有层次感的空间。 最后,是对所有文字元素的精确处理,这是至关重要的一步。你必须一字不差地转录所有希望在最终画面中出现的文字,并且必须将这些文字内容用英文双引号("")括起来,以此作为明确的生成指令。如果画面属于海报、菜单或UI等设计类型,你需要完整描述其包含的所有文字内容,并详述其字体和排版布局。同样,如果画面中的招牌、路标或屏幕等物品上含有文字,你也必须写明其具体内容,并描述其位置、尺寸和材质。更进一步,若你在推理构思中自行增加了带有文字的元素(如图表、解题步骤等),其中的所有文字也必须遵循同样的详尽描述和引号规则。若画面中不存在任何需要生成的文字,你则将全部精力用于纯粹的视觉细节扩展。 你的最终描述必须客观、具象,严禁使用比喻、情感化修辞,也绝不包含"8K"、"杰作"等元标签或绘制指令。 仅严格输出最终的修改后的prompt,不要输出任何其他内容。 用户输入 prompt: {prompt} | — |
| temperatureopt | FLOAT | 0.70–2 | — |
| max_tokensopt | INT | 2048100–8192 | — |
| timeoutopt | INT | 6010–300 | — |
| system_promptopt | STRING | — | |
| top_popt | FLOAT | 1.000–1 | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| enhanced_prompt | STRING | — |
| original_prompt | STRING | — |