The node that reproduces another UI's embeddings ships an empty comparison table

The comparison that justifies the node is a table of six empty cells

The section that promises identical output describes its evidence precisely and then shows none of it. It states that the images can be dragged into the graph editor to load their workflows, and it fixes the conditions: one named checkpoint in a version 1.5 configuration, eighteen steps, one sampler. Then comes a table with three columns, headed by the two front ends and by two parser names, followed by two body rows in which every cell is blank. Six empty cells where the visual comparison should be. Two image comparison links are offered instead, as bare URLs on their own lines, which means the evidence lives on a third-party site and the repository carries a caption for a figure it does not contain. Everything needed to reproduce the comparison is specified except the comparison.

Multi-prompt weighting diverges by design and the fix is arithmetic

One option carries the most important sentence in the file and it is inside a list. When a prompt is split by the conjunction keyword, each resulting prompt is given a guidance scale of the base scale multiplied by its own weight and then divided by the number of positive prompts. The other front end gives each prompt the base scale times its weight, with no division. To make the two agree, the documentation says you can add a weight equal to the prompt count to every prompt, or set the base scale to the base scale multiplied by that count. So for any graph using more than one prompt the node produces something different on purpose, and closing the gap means editing every prompt in the node by hand. The single-prompt case, which is the common case, is where the exactness claim actually holds.

A parser named fixed attention still changes the encoding pipeline

Six parser values are offered and the descriptions are short. One is described as leaving the prompt untampered with. Another is the native path, the way the graph editor handles everything by itself. Another strips whitespace, newlines and special characters. Another delegates to a third-party prompt library. One is described as using the editor's parser but encoding tokens the way the other front end does. A callout then states the rule that governs the whole table: every parser except the native one uses the other front end's encoding pipeline. So the value whose name suggests attention is left alone belongs to the set that does alter attention handling. The name describes the prompt text and the pipeline describes the embedding, and nothing in the file reconciles the two readings.

The settings node may need recreating after any update

The documentation contains a compatibility warning stated in passing. The settings node can change whenever it is updated, so you may have to recreate it to prevent issues. For a node whose entire value is that its settings live inside a saved workflow, that is a statement about other people's files breaking, not just about your own. The same paragraph also carries a first-person note in an otherwise third-person document: the node was made to explore the settings found in the other front end. That framing matters, because a node described as an exploration is one whose defaults may still be moving. Its behaviour is otherwise well specified: it acts like a reroute node, its inputs can be swapped after they are connected, and settings apply locally based on links rather than globally.

Two numbering schemes, two names for one directory, and a truncated step

The file opens with a two-item numbered contents list, then an unnumbered block of three bullet links covering the reproducibility tips, the questions and the installation. Those sections then appear in the document in an order the contents block does not match, with the main node first and the settings node before them. The installation section ends mid-word at its fourth step of the manual method, so the last instruction of the third method is missing. And the second method is described in prose as cloning into the extensions directory while the command it gives immediately below uses a different directory name for the same place. Three small inconsistencies in the part of the file a first-time user depends on most.

Three image slots are captions with nothing in them

Three places in the document are built to hold an image and hold none. Under the main node there is a nested row containing a single empty centred paragraph. Under the settings node there is a div whose only content is a paragraph reading as a caption for a picture. Under the manager install path there is a third div with a caption in the same shape. So a reader gets three captions and no pictures. The repository does contain a web directory, which is where a front-end extension would live, and the file does describe a right-click menu on the node, so the interaction being documented is implemented somewhere; the gap is in the documentation rather than in the code. Given that the project's central claim is visual equivalence, the missing figures are the least convenient ones to lose.

Registry metadata with an empty icon and three spellings of one name

The packaging manifest carries a block for the node registry: a publisher identifier, a display name, and an icon field set to an empty string. An empty string is not the same as omitting the field; it is a declaration that the icon is deliberately blank, and a listing that reads the block will render nothing. The same block also fixes the display name in mixed case, while the package name in the same file uses all lowercase with a word separator, and the repository uses the mixed-case form. Three spellings of one node pack across three systems that each index it separately. A registry that matches on the display name will not match the folder on disk without a case-insensitive comparison.

Two dependencies, both in the path that has to stay still

cd path/to/your/ComfyUI/custom_nodes
git clone https://github.com/shiimizu/ComfyUI_smZNodes.git

The manifest declares exactly two runtime requirements: a parser-generator library with a floor of a specific minor version, and a prompt library with no version constraint at all. Both belong to the encoding path that exists to reproduce another interface's output, and the native parser needs neither. A second loose declaration matters as much: the manifest states no build backend and no interpreter floor. Neither omission blocks loading a node pack from a directory, which is how the file's own installation instructions work, but both mean nothing constrains what the code runs against. For a project whose stated purpose is byte-identical output, an unconstrained library in the tokeniser is the line to read twice before trusting a saved workflow.

Editorial conclusion

smZNodes is worth installing if you need images that match ones you already made in a different interface and you need them to be identical rather than similar, because the node reuses the other front end's own parsing and encoding path rather than approximating it, and the settings node exists to close the remaining default gaps one at a time. It is not the right tool if your prompts lean on weighting and attention syntax and you expect exactness out of the box, because the multi-prompt case diverges by design and the fix is manual arithmetic on every prompt. Before you rely on it, read the multi-prompt option rather than the headline, pin the prompt library yourself if you need output to stay still over time, and treat any saved workflow containing the settings node as something you may have to rebuild, which the file warns about without quite saying how.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. shiimizu/ComfyUI_smZNodes on GitHub