XB-llama - 🧹 清理状态

Here's a failure mode that's baffling the first time it hits you: you turn on save_states on XB_llamaInstruct so a conversation can continue across runs, and then a week later the model is still answering with context from the old session - characters from a story you wrote once, a system prompt you've since deleted, a mood that stopped being relevant five workflows ago. XB_llamaCleanStates is the reset button for that in-memory state. Drop it in, pick how much to wipe, and the LLM's conversation memory starts fresh.

It exists because the llama nodes keep saved conversation history in memory, keyed by a state ID, and memory is the one thing a restart of ComfyUI doesn't clear the way you might expect - actually, a full ComfyUI restart does clear it (it's in-process state), which is why the cleanest "bug report" is "it's fine after restart but weird on the second run." When you want to reset without a restart, mid-session, this is the tool.

Inputs

• any - a passthrough wire of any type. Its only job is to let you chain this node into your workflow's data flow so it executes at the right point. Whatever you put in comes out unchanged on the other side.
• state_uid - which state to clear. −1 (default) clears everything - all saved messages and all system-prompt records. A specific positive ID clears just that conversation.

Output

any - the same value you wired in, passed through untouched. This is a side-effect node; the output exists purely so you can position it in the graph.

Installing it

Standard XB_ToolBox install (ComfyUI Manager → XB_ToolBox, or git clone), then restart. No dependencies - it's a thin wrapper over the pack's in-memory state store and works even without llama-cpp-python installed (though with nothing to talk to, it's not very useful).

How to use it well

The practical pattern is a "new story" reset button: wire XB_llamaCleanStates (state_uid −1) ahead of your instruct node, and every run of the workflow starts with a blank conversation. If you're running multiple conversations in one workflow (say, two instruct nodes with different state_uids from XB_llamaParameters), clear only the specific ID you want rather than nuking both. The state_uid output from XB_llamaInstruct tells you exactly which ID a given node is using, so the pairing is: grab that ID, clear it here when you want a do-over.

The one trap: because save_states writes history to memory on every run, a workflow with it enabled and no clean node accumulates context run after run - the model gets slower and more "committed" to old choices. If you're seeing results drift from what you set this week, a clean-state node wired before the instruct node is the fix. If you never use save_states, this node has nothing to do and you can skip it entirely.