A changelog readme, no GitHub releases, and a node added twice

The readme is a changelog and the releases are not on GitHub

The repository publishes no GitHub releases, so the only version history is the page itself, which opens with a news list instead of an explanation. That list runs from 1.9.3 in February 2025 through 2.0.0 in March of that year, a dense 2.x series, a 3.0.0 in January 2026, and 3.1.0 in July with 3.2.0 on September 30, 2026. Each entry links into a separate update file in the repository by version anchor, so the details live in two places and only the headlines live on the page. The project metadata names the current version as 3.2.0, which matches the top entry, and that is the version marker a script can read. What is missing is the framing a visitor needs: there is no statement of what the node set does as a whole, which models are supported, or what the registry entry is called. The documentation site linked from the repository homepage is where that has to come from.

One comparison node is added twice, two months apart

Read the list as a sequence rather than a set and the history shows two anomalies worth knowing. The first is a duplicate: version 2.4.0 in June 2025 says it added a crop node, an image comparison node and a colour input node along with a second segmentation node, and version 3.2.0 in September 2026 says it added a new resolution selector and image compare node. Both use the same words for the same idea, and nothing on the page says whether 3.2.0 reintroduces a node that was dropped, renames one, or duplicates it under a new name. Workflows that saved a reference to the older node are the ones affected. The second anomaly is quieter: two releases share a date. Version 2.2.0 and version 2.2.1 are both dated the fifth of April 2025, which means a feature release and a follow-up landed the same day and the log cannot tell you which one a user ended up with.

The 2.x line had six patch releases and the 3.x line has none

The numbering is unusual enough to be worth reading as a signal. The 2.9 series alone runs 2.9.0 in August 2025, then 2.9.1 in September, 2.9.2 and 2.9.3 in October, 2.9.4 and 2.9.5 in November, and 2.9.6 in December: six releases inside five months, four of them within a single month. After that the project went to 3.0.0 in January 2026 and has since produced 3.1.0 and 3.2.0, with no patch releases at all. Features are landing in minor bumps: version 2.2.0 alone added six nodes for combining and enhancing masks, version 2.5.0 added three more plus two models plus batch support, and version 2.7.1 split image loading into three separate nodes and rebuilt the stitching node. So the patch number carries hotfixes on the old line, while the new line puts features and fixes in the same step, and there is no statement of a compatibility promise for either.

Startup from about fifteen seconds to under a tenth

The current entry carries the only performance numbers on the page. Version 3.2.0 claims ComfyUI startup was optimised from roughly fifteen seconds to under a tenth of a second, which is a two-order-of-magnitude claim about a thing a user notices every launch and cannot check from a node list. The same release adds an unload toggle available across all nodes, described as instant release of GPU memory, which matters for the segment-and-try-another loop that these models invite. It also adds native Apple Silicon acceleration on macOS, so the project stopped being a discrete-GPU-only tool in its newest version, and a new segmentation node with safetensors support, which names the two weight files it expects: one for the main checkpoint and one half-precision multiplex variant. A resolution selector node also arrives here, so a single version moves model format, memory management, hardware support and input sizing at once.

Two dependency files disagree about transformers

The package metadata and the requirements file list the same project twice, and they do not agree. The requirements file asks for a hub client, a background-removal library, the segment-anything package, a grounding package, OpenCV, both CPU and GPU runtime builds of ONNX, protobuf, and then three more that the metadata does not mention at all: the transformers library with a floor of 4.30, diffusers with a floor of 0.18, and, under comments for the newest segmentation model, a video decoder, a text-fixing library and a typing extensions package. The protobuf constraint differs too, capped below version 6 in the metadata and open-ended in the requirements file. Both files install the CPU and GPU runtime packages together, which is the same pair on every platform whether or not a GPU is present. There is also a commented-out reference to a Windows build of a kernel library, suggesting someone hit a Windows-specific problem and worked around it by disabling the dependency rather than solving it.

Nine models in the metadata and thirteen in the first paragraph

The repository summary names nine models: a background-removal model, two inspection models, two of the same family numbered one and two, a matting family, and the three segmentation generations with a grounding model. The first paragraph of the readme names four more, adding a fine-tuned matting model, a captioning model, an object detector and an inpainting model. The project metadata repeats the nine-model list in its own description, with slightly different wording, so the same repository carries two different inventories of what it wraps. The individual nodes then arrive in pieces: a matting node in version 2.9.0, a text-prompted segmentation node in 2.8.0, a second segmentation generation in 2.4.0, and the fine-tune added to the matting node in 3.1.0, described as aimed at transparent objects, camouflage, text and logos, glow and visual effects, and illustrations, with a sensitivity parameter alongside it. None of that is visible from either summary.

Translations, locales and a category path full of emoji

Two structural details are visible in the repository rather than the news list. There is a locales directory and a web directory beside the implementation, which is where the interface translations and the browser-side code live, and the version history shows internationalisation arriving in 2.1.0 with dynamic language switching, followed by translation error fixes in 2.2.0 two weeks later. That is the usual order and a useful signal about the cost of a multi-language interface. The other detail is the node category path introduced in 2.0.0, which reads as a laboratory prefix, a utilities prefix and an image prefix, each carrying an emoji. It is a small thing that says something about the intended audience, and it is also the kind of string that changes between releases. A registry block in the package metadata names the publisher and display name, with an empty icon field, which is why the listing looks bare in a registry browser.

Editorial conclusion

Use it if you run ComfyUI and want background removal and segmentation as nodes you can chain, and read the version list rather than the summary, because the summary is two years out of date relative to the log. Three things to verify before you build a workflow on it. Check the update notes for your version rather than the top of the readme, since the newest entry is what describes the current node set and the two lists of models in the page disagree. Pin your transformers version deliberately, because the page records three separate compatibility efforts against that library and the project metadata does not list it as a dependency at all. And remember what the licence covers: GPL-3.0 applies to the node code, while the weights it downloads are separate artefacts placed in the models directory by name.

Frequently asked questions

Official sources

1. 1038lab/ComfyUI-RMBG on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README