save redis memory

An LLM node's conversation history normally lives and dies with the graph run it's part of - restart ComfyUI, or start a fresh queue item, and there's nothing left of what was said before. save redis memory is comfyui_LLM_party's way around that: it writes your conversation history out to a Redis server under a key you choose, so it survives past the run that produced it.

It sits in the pack's memory category - the tools built for exactly this problem, giving an agent something closer to persistent state instead of a conversation that resets every time.

How it works

You supply the conversation text (history) and a name to store it under (history_key), plus where your Redis server actually lives (redis_host, redis_port), and the node writes that history to Redis under that key. A matching load-side node elsewhere in the pack's memory tooling would be how you'd read it back into a later run - this node covers the save half of that round trip.

The inputs and outputs that matter

• history - the conversation text to persist. Typically wired straight from an LLM node's own history output.
• history_key - the name this gets stored under in Redis. Choosing this deliberately (per user, per session, per project) is what makes it possible to keep multiple separate conversations in the same Redis instance without them colliding.
• redis_host (default localhost) / redis_port (default 6379) - where your Redis server is. The defaults assume Redis running on the same machine as ComfyUI.

Output: history_key (STRING) - echoes the key back out, which is handy if you built it dynamically upstream (say, from a user ID) and want to pass the same value along to whatever reads this memory back later, rather than typing it twice.

The thing worth knowing before you wire this up

This node needs an actual Redis server running and reachable - it doesn't ship one, doesn't start one for you, and the pack's base requirements.txt install doesn't stand one up either. That's on you: a local redis-server install, a Docker container, or a hosted instance somewhere. If you've only ever installed this pack's Python dependencies and never touched Redis itself, this node will fail immediately, and that's expected rather than a bug in the node.

How to install it

Search comfyui_LLM_party in ComfyUI Manager and install, then restart. Manual route:

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

Run pip install -r requirements.txt from inside the pack's folder using ComfyUI's own Python, then restart. That covers the Python Redis client this node needs to talk to a server - it does not cover the server itself, which is a separate piece of infrastructure you're responsible for standing up.

Common issues & troubleshooting

Connection refused, or a timeout. The single most likely cause is that nothing is actually listening on redis_host:redis_port - confirm a Redis server is running and reachable from wherever ComfyUI is running before assuming the node's logic is broken. If ComfyUI is in a container and Redis is on the host (or vice versa), localhost may not mean what you think it means across that boundary.

It connects fine but you can't find your data later. Redis keys are exact-match - a history_key that's even slightly different between the save and the eventual read (a typo, a different casing, an unintended dynamic value) means you're writing and reading two different keys that happen to share a Redis instance. Log or display history_key at both ends while you're debugging this.

You want this to survive a Redis restart. Whether your data outlives a Redis restart depends entirely on how that Redis instance is configured for persistence (RDB snapshots, AOF, or neither) - that's a Redis administration question, not something this node controls.