BlehBlockOps

This is the "if you know, you know" node in the pack - instead of shipping a dozen narrow nodes for every block-patching idea, blepping gives you one general mechanism and lets you write your own. It's powerful enough that the README uses it to reimplement two other named techniques, FreeU and Deep Shrink, as its own worked examples.

The shape of it: rather than a fixed set of widgets, you write a YAML rules list. Each rule has an if condition - what block type it applies to, what stage, what percentage of sampling - and an ops list describing what to actually do to the tensor at that point: scale it, blend it, filter it, skip a connection, and so on. It's a small domain-specific scripting language living inside a text box.

The README's two examples are worth understanding even if you never write your own rules, because together they're the best documentation of the concept available. The FreeU V2 example uses slice, target_skip, and ffilter ops on specific output-block stages to reproduce that technique's effect. The Deep Shrink example is arguably more useful to read first if you've used BlehDeepShrink: it applies a scale op at a specific input block up to a time cutoff, then an unscale op on the output blocks - which is, more or less, what the dedicated BlehDeepShrink node is doing internally, minus the multi-block convenience and fadeout curve that node adds on top. If you've ever wondered exactly what Deep Shrink does under the hood, that example is close to the literal answer.

Inputs: model (required), rules (required, multiline STRING - your YAML goes here). Optionally, sigmas_opt takes a SIGMAS input, which the node needs whenever a rule's if condition references percent-of-sampling, since translating "35% through sampling" into an actual sigma value requires knowing the schedule. Output is a patched MODEL.

Here's the honest limit of what can be said from the sources available for this article: the specific op names, their argument order, and the full set of valid if condition types live in a separate extended documentation file the repository links to (docs/blockops.md) rather than in the node's own info_schema or the main README - so this isn't something you can reliably reverse-engineer from the widget alone. Treat the two README examples as your starting templates, not as the full reference, and go read that extended doc in the repository before writing a rules list from scratch.

Install is the standard route - ComfyUI Manager, or a manual git clone https://github.com/blepping/ComfyUI-bleh into custom_nodes plus a restart. No extra Python dependencies.

A practical note on debugging: because rules are plain YAML text with no graph-level validation, a typo or a misunderstood op argument usually doesn't throw a helpful error - it just means your patch silently doesn't do what you expected, or does something else entirely. Start from one of the README's two worked examples, change exactly one thing, and re-run before you build anything more elaborate. Given how little is documented about this node compared to the rest of the pack, that's the practical difference between debugging in an afternoon and debugging for a week.