Start Dialog

start_dialog is the chat-specific sibling of start_anything (same pack, same category) - same idea of resuming across queue runs, but shaped specifically around a conversation instead of an arbitrary value. Where start_anything hands you back whatever type you gave it, start_dialog hands you back a user_prompt and a dialog_id - the two things an LLM node further down the chain actually needs to keep a running conversation coherent.

The pattern: on a fresh run, init_dialog becomes the opening user_prompt, and a new dialog_id gets minted to track this conversation. Flip is_reload on, and instead of starting over, it resumes an existing dialog - which is exactly what you want if your agent workflow needs to keep responding to a user across multiple separate ComfyUI executions rather than re-explaining itself from scratch each time.

Inputs and outputs that matter

• init_dialog - the opening message/prompt text that kicks the conversation off.
• is_reload - on, resumes a prior dialog instead of starting fresh; off (the default), starts a new one.

Two outputs: user_prompt, the string to feed into your LLM node's user-input side, and dialog_id, a string identifying which conversation this is - the value you'd hand to a memory node if you want this specific conversation persisted somewhere durable (this pack's save_SQL_memo is the SQL-backed option, if you want the conversation to survive outside a single ComfyUI install).

Installing it

Search comfyui_LLM_party in ComfyUI Manager and install, or clone directly:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

pip install -r requirements.txt inside your ComfyUI Python environment, then restart. This node has no model dependency of its own, but it ships inside the full pack, which is large - LLM APIs, local model loading, RAG, TTS, and a long list of tool nodes all come along with it. The README's only_api branch is the lighter option if you only want API-based calling and not local/GGUF model support.

Common issues

The most common way this trips people up is confusing "new conversation" with "continuing one." If you leave is_reload off on every run, you'll get a fresh dialog_id every single time - which means any memory node keyed off dialog_id never actually accumulates a real conversation history, it just writes a new, unrelated row each run. If your workflow is supposed to feel like a continuous chat across queue executions, is_reload needs to be on for every run after the first.

Also worth knowing before you build a big loop around this: because it's specific to dialog/chat, it won't help you resume arbitrary non-conversation state - that's what start_anything is for. Mixing the two up (using start_dialog where you actually need to persist, say, an image-generation loop's state) will leave you fighting the node instead of your actual workflow.