ComfyUI_toyxyz_test_nodes: a personal node pack for ComfyUI

One maintainer's tool belt, packaged as a ComfyUI custom node

The description is unusually blunt about what this repository is: a custom node that collects the tools the author uses frequently. That framing explains both the contents and the way they evolve. There is no product scope, no roadmap and no issue backlog with themes in it. There is a person adding tools to their own workflow and publishing the result.

The update log in the README reads exactly like that. Over several years the author has appended nodes on the dates they were needed, from the 3D Pose Editor and ComfyCouple Region painter nodes added on 2026-10-13, back through the booru tag prompter on 2026-09-29, the image prompter on 2026-09-16, the minimax h3 camera node on 2026-09-14, the Minimax-H3-prompter node on 2026-08-25, and the Draw area mask, ComfyCouple Region multi and Crop area mask nodes on 2026-04-18. Earlier entries cover lora hook support in the ComfyCouple Region node from 2025-10-30, the Openpose Editor Node and pose interpolation from 2025-10-21, a visual area mask node from 2025-03-10, and the export glb node from 2024-11-04.

The repository is not archived and the last push was on 2026-10-17, so the pattern continues. What you are evaluating is a live personal collection, and the update log is the only changelog you get.

ComfyCouple, pose editing and masking form the core of the pack

The directory names give a good sense of the clusters. ComfyCouple/ holds the region and mask work: the ComfyCouple Region node, ComfyCouple Mask, Comfy Couple Region Extractor, a multi variant, an Anima support change from 2026-04-16, and lora hook support added on 2025-10-30. openposeeditor/ holds the Openpose Editor Node and pose interpolation. TiledDiffusion/ is a separate subproject directory. CaptureCam/ is the webcam and screen capture area, and it is the one that has its own setup step.

Masking and pose work share a purpose in an image pipeline. A region mask lets you restrict a generative step to a defined area rather than the whole canvas, which is what you need when you are editing one part of a frame and want the rest left alone. A pose editor lets you specify body positions so a generation or a control pass has a target skeleton rather than a vague description. The crop and draw area mask nodes from 2026-04-18 sit in the same family, and the depth to normal and remove noise for normal map nodes from late 2024 are the kind of preprocessing utilities that the same user would reach for.

What the repository does not give you is a compatibility matrix. The README does not state which ComfyUI version, which model family or which scheduler any of these nodes expect, so you are reading the source for each node you plan to use rather than checking a table.

Installing means cloning into custom_nodes and running a Windows setup script

The installation is two steps. The first is to clone the repository into the ComfyUI custom_nodes path, and the README gives the command:

git clone https://github.com/toyxyz/ComfyUI_toyxyz_test_nodes

The second step is to run setup.bat inside the CaptureCam folder, at the path ComfyUI/custom_nodes/ComfyUI_toyxyz_test_nodes/CaptureCam. That is a Windows batch script, and it exists because the capture features need native screen and camera access. The capture nodes are also the ones the README flags as needing a repeat run: the 2023-11-24 entry for the save image to path, render preview, export video and face detection nodes notes that after the update you need to run CaptureCam/setup.bat one more time.

That Windows assumption is the practical limit on this repository. The core node work is Python and cross-platform, but the camera and screen capture path is tied to a batch file, and requirements.txt lists pywin32 among the dependencies, which is a Windows-only package. On macOS or Linux you can install the pack and use most of it, but the capture setup step is not available to you as written.

The dependency list is short and mostly familiar: numpy, torch and opencv-python in the pyproject dependencies, with mss, pywin32, trimesh, polygraphy and matplotlib added in requirements.txt. The pyproject metadata also names the ComfyUI publisher as toyxyz and the display name as ComfyUI_toyxyz_test_nodes, which is what makes the pack appear with that name inside ComfyUI.

The Minimax-H3-prompter turns a shot timeline into a prompt, not a video

The largest single feature is the Minimax-H3-prompter, which builds audiovisual prompts for MiniMax H3 from a Shot/Move timeline plus optional image, video and audio references. The README is explicit about the boundary: it generates prompts, not the final AI video.

The interaction model is a timeline. You choose a model, mode and duration, with an Auto setting that selects the mode from your references, and a practical starting range given as 5 to 15 seconds where the displayed frame count is H3-aligned. You enter subject, action, setting and camera instructions in the prompt field, and a Shot starts a new take while a Move continues the same Shot without a cut. Boundaries drag to adjust timing. Per Shot and Move you can set visual style and camera style, where camera style adds handling such as handheld or stabilized movement without replacing the requested path or speed.

Generation is then a button press, with the Enhance setting defaulting to Normal: None is concise, Normal expands the request, and Strong produces a longer, richer description. The outputs are named, and they are prompt outputs. The node emits generated_prompt and length, which you connect to your H3 workflow, and Auto Run makes it generate when ComfyUI executes the node. The README notes that the queued generation shows ComfyUI's native green progress bar by stage rather than by token count or remaining time, and that the separate Generate Prompt button keeps its own status log.

Five reference modes decide what the H3 node can do

The reference handling is where the mode list does its work. There are five: T2VA for text, I2VA for a first frame, FL2VA for first and last frames, L2VA for a last frame, and REF2VA for reference generation or editing. The choice determines what the node can honour, and picking a mode that does not match your input is the most common source of disappointment.

Image references can be a first frame, a last frame, a frame or a subject. Frame anchors drag to exact timeline positions while first and last anchors stay fixed, and reference strength controls subject retention. Video references cover editing, continuation and motion or action timing, and clips move and trim on the timeline with only the visible source interval used. For motion transfer the node expects explicit source-to-target mappings in the prompt, with the README's own example of a red figure standing for a woman and a blue figure for a man. Motion references include camera behavior but do not copy source appearance or scenery. Audio references require you to select the intended reuse role, because loading a video alone does not request audio reuse.

Aliases are written with the @ sign, and reference order has to match the downstream H3 slots, which is a sharp edge to hit if your list is long. The node's own layout tries to contain that: long reference lists, media timeline tracks and camera controls scroll inside the node instead of expanding it, and saved node sizes stay adjustable.

Large videos spill to disk instead of eating RAM

The memory behaviour is the most concrete engineering detail in the README, and it is worth understanding before you feed the node a long clip. Reference videos are decoded sequentially into the selected 24 fps frames, preserving source resolution, float32 output, display rotation and trimmed audio. Large video and camera buffers, defined as 256 MiB or more or when RAM is low, use temporary file-backed storage under test/cache/h3_video_memory/.

Files are released when their last tensor or cached output is released, and existing ComfyUI RAM-cache eviction is used without unloading models or changing global settings. The README is also clear that this only moves the buffer: downstream resizing and VAE encoding still need memory, so disk space has to be sufficient and the model still has to fit.

The Qwen side has a similar discipline. Qwen3.8 27B is stated to support all modes and Normal and Strong expansion, and each Qwen task reuses one llama-server for reference analysis and final writing, then releases it on completion, cancellation or failure. Text-only tasks do not load the vision projector, analysis and writing use separate requests so the full image conversation is not accumulated in the final writing context, and in R2V each source analysis is included only once even when several targets share it.

Restoring a saved workflow without losing your connections

The prompt and camera state can be saved per Shot and Move. Camera options cover framing, viewpoint, lens height, angle, route, roll and composition, with Camera level setting height independently of Angle, and Movement range and Speed guiding the prompt rather than the preview. User camera instructions take priority over the generated values, and the proxy preview is described as illustrative rather than a guarantee of the generated video's framing.

One display dropdown and a Copy button share the same text area, offering the latest generated result, the raw prompt with system and user input including the actual reference analysis after generation, and the camera prompt before user text overrides are applied by Qwen.

The restoration behaviour is where the design is most defensive. Restoring a workflow preserves existing output connections and saved prompts until the project and camera inputs are ready, and when saved data or output names are ambiguous the execution log warns and preserves the existing slots rather than deleting them. Outputs are named image_N, frame_N, video_N and audio_N as applicable. For a node that sits in the middle of a long pipeline, that is a sensible default: a failed restore should cost you a warning, not a rebuilt graph.

No releases, GPL-3.0, and an unpublished compatibility story

The repository has no GitHub releases, so there is no artefact to pin and no upgrade path documented. The pyproject file carries a version string of 1.0.6, but with no tagged releases behind it that number tells you nothing about what changed or when. The licence is GPL-3.0, and the licence file is the one named in the pyproject metadata, so the copyleft terms of that licence apply to the code as distributed.

For an internal workflow tool that is not a blocker. For anything you ship to customers, it is a real consideration, because GPL-3.0 obligations travel with the code you incorporate, and no exception is stated in the repository documentation. This is not legal advice, and the right step is to read the LICENSE file and talk to whoever owns that question in your organisation.

The wider point is that this is a personal collection, not a maintained platform. The camera and prompt work is the part most in need of attention as the underlying models change, and nobody has committed to keeping it aligned with them. Vendor the code you use, keep it in your own repository, and treat every node as code you now maintain.

Editorial conclusion

Adopt ComfyUI_toyxyz_test_nodes if you already run ComfyUI and want a specific missing tool, such as a ComfyCouple region mask, a pose editor, an export glb node or the shot-based prompt builder, and you are willing to vendor and maintain the code yourself because the repository publishes no tagged releases. Do not adopt it as a shared, pinned dependency for a team, since there is no versioned artefact and the pyproject version is a static string rather than a release history. Before you rely on it, run the clone into ComfyUI/custom_nodes, execute setup.bat inside the CaptureCam folder on Windows if you need the camera nodes, and read the code for the nodes you plan to use, since the GPL-3.0 licence and the unversioned state both put the responsibility on the integrator.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. toyxyz/ComfyUI_toyxyz_test_nodes on GitHub