Always Execute

AlwaysExecute is the opposite of CommandPickerServing, and they're usually deployed as a pair. Where the picker runs a branch only for one specific command, AlwaysExecute runs its connected output for every command - registered or not. The README puts it plainly: "this will execute for ALL commands, no matter if the commands are registered or not." It's the catch-all output gate.

Why would you want that? A few genuinely useful jobs. The most common is a fallback reply: when a user types something that matches no registered command, the entry point node would normally just drop the message silently. With an AlwaysExecute node attached to a ServingTextOutput, that unregistered message still gets a response - something like "I don't know that command, try !help" - which makes the bot feel alive instead of mysteriously mute. It's also handy for behavior you want on every request regardless of routing: logging the prompt, incrementing a counter, sending a "processing…" status message, or running a shared preprocessing branch. If a branch should never be skipped, AlwaysExecute is the gate for it.

Mechanically it's the same lazy-evaluation trick as CommandPickerServing, just with the filter removed. Its check_lazy_status registers a global catch-all in the command registry - which is also why adding one AlwaysExecute node makes even unregistered commands flow through the graph - and then unconditionally pulls in serving_config and should_execute. The connected output executes, full stop.

Inputs: serving_config and should_execute (the SHOULD_EXECUTE signal from an output node like ServingOutput or ServingTextOutput). No outputs of its own - it's an output node that gates execution.

One thing to watch: because it fires on everything, putting a heavy branch behind AlwaysExecute means every request pays the cost, even the ones that also hit a specific picker. Keep the catch-all branch cheap - text replies, logs, counters - and put the expensive generation behind CommandPickerServing branches. If you attach both a picker and AlwaysExecute to outputs, both can run for the same command, so structure the graph so they don't fight (for example, pickers handle the real commands, AlwaysExecute handles the unknown ones, and they reply through separate text outputs).

Install is the shared pack route - ComfyUI Manager, or git clone into custom_nodes plus pip install -r requirements.txt. No extra dependencies, no models. And the pack-wide rule still bites: Auto Queue on, or the node runs once, registers its catch-all, and never sees another command.