load json file memory
Load json file memory — comfyui_LLM_party
- system_prompt
- user_history
- history_path
Every LLM call in ComfyUI is stateless by default - run the graph twice and the model has no idea the first run ever happened. This node is the simplest fix in comfyui_LLM_party's toolkit for that: it persists conversation history to a plain JSON file on disk, so an agent you're building can actually remember what happened last time.
That's the whole mechanism. Point it at a file path, and it reads whatever history already lives there, hands it to your LLM node alongside a system prompt, and (implicitly, since it's a memory node in an agent pack) writes new turns back to that same file as the conversation continues. Use the same history_path across runs and you're continuing one ongoing memory thread - a persistent assistant, a running project log, whatever you're building. Point different runs at different filenames and you get separate, independent memories - handy for per-user or per-session isolation without needing any real database behind it.
This is deliberately the lightest of the three memory backends this pack ships. The other two - Redis-backed and SQL-backed - need an actual server running somewhere and are built for concurrent, multi-user, or production setups. A JSON file needs nothing but a writable disk, which makes this the one to reach for first: testing an agent locally, a single-user assistant, anything where you don't want to stand up infrastructure just to give a bot a memory.
Inputs and outputs. system_prompt is a required multiline STRING - the instructions that frame the whole conversation, same as any system prompt you'd hand an LLM directly. history_path defaults to 1.json; change the filename per distinct conversation you want to keep separate. The node passes all three straight through as outputs - system_prompt, user_history, and history_path - which is the pattern this pack's memory nodes use to feed an LLM node its context while also carrying the path forward if you need to reference it again later in the graph.
Installing it. load json file memory ships with the full comfyui_LLM_party pack - no separate step. Install via ComfyUI Manager (search "comfyui_LLM_party") or cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt from inside the project folder using your ComfyUI Python environment, and restart. This particular node needs no external service, no API key, and no database - just a location on disk it can write to - so it's one of the lowest-friction nodes in the pack to get running.
Where it actually breaks. The main thing to check is that history_path points somewhere the ComfyUI process can actually write, with permissions to create and update the file - 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, since the file either never gets written or gets wiped between calls. If you're relying on this for genuinely persistent memory across separate runs on a remote or ephemeral execution environment, confirm the filesystem you're writing to actually survives between runs before trusting it. Beyond that, if the pack fails to load at all rather than just memory misbehaving, that's this project's large requirements.txt hitting a conflict somewhere unrelated to this node specifically - check the ComfyUI console for the real error.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| system_prompt | STRING | — | |
| history_path | STRING | 1.json | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| system_prompt | STRING | — |
| user_history | STRING | — |
| history_path | STRING | — |