Interpreter Function

Sometimes the cleanest way to glue two parts of an agent workflow together is a few lines of Python - reshape some text, do a bit of arithmetic, parse something the built-in converter nodes don't handle. interpreter_function is that escape hatch: a code box right inside the graph. You write the code, it runs, you get back what it printed and what variables it defined.

This is different from its sibling interpreter_tool, which is worth being clear about up front: interpreter_tool hands code-execution capability to an LLM, which then writes and decides when to run code on its own. interpreter_function is the other direction - you write fixed code once, as a graph author, and it runs every time this node executes. No LLM involved unless you wire one in yourself.

How it works

You write Python into code_str. It executes in place, and the node captures three things separately: what got printed to the console, what variables ended up defined, and a combined view of both.

The inputs and outputs that matter

• code_str (multiline, default print('Hello, party!')) - your code. This is the whole input; whatever you write here is what runs.
• is_enable - standard bypass toggle.

Outputs: console_output - anything your code printed. defined_variables - the variables your code created, as text. all_output - a combined view of both. Wire whichever one matches what you actually need downstream - pure printed text, structured variable state, or everything at once.

How to install it

Via ComfyUI Manager: search comfyui_LLM_party, install, restart. Manually:

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

Then pip install -r requirements.txt from inside the pack folder using ComfyUI's own Python, and restart. Nothing extra needed for this node specifically - it runs on whatever Python environment ComfyUI itself is already using.

Common issues & troubleshooting

Be honest with yourself about what this node actually is: unrestricted code execution. ComfyUI's broader ecosystem already has a documented problem with custom nodes running arbitrary Python with full OS-level access and no sandbox - that's exactly what this node does too, deliberately, as its entire feature. It's not a flaw specific to this node; it's the nature of an in-graph interpreter. The practical takeaway: don't run a workflow you downloaded from someone else without reading what's actually in code_str first, the same caution you'd apply to running any unfamiliar script.

Output looks empty even though your code clearly does something. Check which output you're actually reading - code that sets variables but never calls print() will show up in defined_variables/all_output but leave console_output empty, and vice versa.

Errors inside your code halt the node. Standard Python error behavior applies - a syntax error or an unhandled exception in code_str will surface as a node failure, not silently skip. Test tricky code outside the graph first if you're not sure it's correct.