save json file memory

An LLM call in ComfyUI is stateless by default - run the graph twice and the model has no idea the first run happened. This node is the write half of this pack's simplest fix: it takes your conversation history and writes it to a JSON file at history_path, so a matching load-side node can read it back in on a later run. If you've seen this pack's load_memo node (which reads a JSON memory file back in), this is its counterpart - the save side of that same round trip.

How it works

You feed it the conversation text and a path, it writes the file, and it echoes the path back out - useful if history_path was built dynamically upstream (per-user, per-session) and you want to pass the same value along without typing it twice.

The inputs and outputs that matter

• history - the conversation history to persist. Required, typically wired straight from an LLM node's own history output.
• history_path - where to write it. Required, no default shown, so set this explicitly.

One output: history_path (STRING) - echoes the path back out. is_output_node: true, so it runs and produces this even with nothing wired to it downstream.

This is deliberately the lightest of this pack's memory backends - no server, no external dependency, just a writable location on disk. Compare that to the pack's Redis-backed memory pair, which needs an actual Redis server running somewhere before it does anything.

How to install it

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt from inside the pack folder using ComfyUI's own Python, then restart.

No API key, no external service - just a writable filesystem location, which makes this one of the lowest-friction nodes in the whole pack to get running.

Common issues & troubleshooting

The file never gets written, or writes fail silently. Confirm history_path points somewhere the ComfyUI process actually has permission to create and update - a read-only location, or a path on a hosted/containerized executor that doesn't persist between runs, will quietly defeat the whole point of a memory node.

You're running on a remote or cloud GPU executor and memory doesn't survive between runs. That's expected unless the filesystem you're writing to is specifically configured to persist - an ephemeral container's local disk resets between runs on a lot of serverless GPU platforms. If you need genuinely durable memory across sessions on infrastructure like that, this plain-file approach isn't the right backend; this pack's Redis- or SQL-backed memory nodes are built for exactly that case.

Two runs are overwriting each other's memory. That means they're both pointed at the same history_path - give each distinct conversation you want to keep separate its own filename, the same way you'd separate keys in the pack's Redis-backed memory nodes.