File write

Its display name in the node list is the plainer "File write," which is honestly the clearer description. It's filed under this pack's "iterator" category, which is the tell for its real use: this is the node you park at the end of a loop - one built with start_anything or start_dialog - to build up a file across repeated runs, rather than something you use for a one-shot save.

The mode field is what decides how it behaves across those repeated runs. Set to a (append, the default) and every execution adds its text onto the end of the same file - exactly what you want if you're assembling a long transcript, story, or log one LLM call at a time. Set to w (write/overwrite) and each run replaces the file's contents instead - useful when you only care about the current state, not the history of how it got there.

Inputs and outputs that matter

• text - the content to write, typically an LLM node's output for that iteration.
• file_path - where to write it. No default is set, so you need to supply a real path.
• mode - a (append, default) or w (overwrite).
• suffix - default _processed, presumably appended when the node builds the actual filename it writes to.
• is_enable - the pack's standard skip switch.

The single output, file_path, echoes back the path that was actually written to - chain it into whatever needs to confirm the write happened or read the result back.

Installing it

Search comfyui_LLM_party in ComfyUI Manager and install, or by hand:

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 - it's plain file I/O - but it's bundled with the rest of this large pack. If all you need is the API-calling side without local model support, the README documents a leaner only_api branch.

Common issues

Two things bite people with file-writing nodes like this in general, and both apply here: the parent directory of file_path usually needs to already exist (most file-write operations won't create missing folders for you), and if you're running on a remote or cloud executor rather than your own machine, the path has to be valid on that machine's filesystem, not yours.

The mode-specific trap is more particular to a node meant for loops: if you leave mode on a (append) and re-run the same workflow on a fresh session without changing file_path, you're not starting clean - you're adding onto whatever was left over from the last run. A stale file from an earlier test can quietly bleed into what you thought was a brand-new output. If you want a genuinely fresh accumulation each time, either point at a new file_path per run or switch to w mode deliberately for the first write in the sequence.