Nodes/ComfyUI-Session-Memory/🧠 Session Memory Reader
ComfyUI Node

🧠 Session Memory Reader

Session Memory Reader

By LatentnautΒ·Created 5 months agoΒ·Updated 5 months agoΒ· 0
🧠 Session Memory Reader
    • session_memory
    • run_count
    • session_id
    β—„existing_sessiondefaultβ–Ί
    β—„new_session_namenew_sessionβ–Ί

    ComfyUI has no memory. Every run starts from a blank slate - the graph is a pure function of its inputs, and if the workflow was empty, the workflow stays empty. That's fine for a one-off render, but it's a wall if you've built an LLM-in-the-graph workflow where a language model writes or refines your prompts. Each run the LLM wakes up knowing nothing about the five runs you just made, so it re-suggests the same dead ends.

    Session Memory Reader is the fix at the front end of that loop. Placed at the start of your workflow, it loads the accumulated session history from disk and hands it to you as plain text - ready to paste into your LLM's system prompt. Your prompt-writer LLM starts the run with context about what you've already tried, what got rated, and what the summary said worked. That's the difference between an LLM that throws darts and one that iterates.

    How it works

    Everything lives in one plain JSON file per session: ComfyUI/custom_nodes/ComfyUI-Session-Memory/sessions/{session_id}.json. The Reader loads it, joins the summary fields from every recorded run into one string, and - if you've rated anything in the Feedback Editor - appends a SESSION_FEEDBACK: block of REPLICATE / AVOID directives. Deliberately, it returns the summaries, not the raw prompts. A summary is compact, LLM-sized context; the full prompt text is reserved for the Feedback Editor, where a human reads it.

    A couple of mechanisms worth knowing. First, the node forces itself to run every single time (it returns float("NaN") from IS_CHANGED), so it always re-reads the file instead of getting cached - ComfyUI's aggressive caching would otherwise skip it. That's the correct behavior for a "reload this file every time" node, but it does cost you the cache behind it. Second, if a run was saved with an empty or placeholder summary, the Reader tries to pull <summary>...</summary> blocks out of the prompt text instead - that's the format the companion "Visual DNA Synthesizer" style workflows use, and it means a missing summarizer doesn't necessarily leave you with nothing.

    The inputs and outputs that matter

    The two inputs are the whole UX, and they changed from the README:

    • existing_session - a dropdown of every session already on disk, plus [CREATE NEW]. The dropdown is built when the node loads, so a session you just created won't show up until you reload the node.
    • new_session_name - if you picked [CREATE NEW], this becomes the session id.

    Forget typing a bare session id. The outputs are what you wire into the rest of the graph:

    • session_memory (STRING) - the accumulated summaries plus any feedback block. This is the one you route into your LLM system prompt.
    • run_count (INT) - how many runs are recorded, handy for logging or gating.
    • session_id (STRING) - pass it on to the Writer and Feedback Editor so every node agrees on the session.

    Installing it

    The pack is Latentnaut/ComfyUI-Session-Memory, and it's a lightweight one - no models, no heavy Python deps, just the standard stuff ComfyUI already bundles.

    cd ComfyUI/custom_nodes
    git clone https://github.com/Latentnaut/ComfyUI-Session-Memory
    

    Then restart ComfyUI. Or open ComfyUI Manager, search for Session Memory, and install from there.

    Gotchas

    Two things trip people up. The sessions/ folder lives inside the custom node directory and is gitignored - if you delete or re-clone the pack, your memory dies with it. Back up that folder if the history matters. And note the README is a step behind the code: it describes a Reader with session_id / reset_session / max_runs inputs, but the version that ships uses the existing_session dropdown instead. Trust what the node shows you, not the README.

    Also, expect an empty output on a fresh session - run_count 0 and an empty string is correct until something writes to it. The Reader is only half the loop; you need its sibling, the Session Memory Writer, at the other end.

    Category🧠 Memory

    Inputs (2)

    NameTypeDefaultDescription
    existing_sessionCOMBOdefaultSelect an existing session, or [CREATE NEW] to use the text box below.
    new_session_nameSTRINGnew_sessionIf [CREATE NEW] is selected above, this will be your new session_id.

    Outputs (3)

    NameTypeDescription
    session_memorySTRINGβ€”
    run_countINTβ€”
    session_idSTRINGβ€”