🦊 Kumiho Tag Revision

Kumiho Tag Revision has the simplest interface in the pack - a kref in, a tag in, a boolean out - and a dirty secret: that boolean is always True. Open the source and the method body is a TODO: Implement actual Kumiho API integration that unconditionally returns success. Feed it a kref that doesn't exist, a tag that's gibberish, nothing at all - True, every time. The name says "tag this revision", the code says "sure, whatever you like."

Which is a shame, because the idea is good and the ecosystem genuinely lacks it. Tags are how you mark a revision as approved, published, ready-for-review or wip so teammates can find the good version of an asset instead of the forty-second iteration. That's the entire point: revision numbers are chronological, tags are semantic. The node's inputs are exactly right for it - revision_kref says which revision, tag (default comfyui-output) says what to call it, and success (a BOOLEAN output) is what you'd wire into a gate or a logger if it meant anything.

Here's the twist that makes the node less useless than it looks: tagging already works - through the save nodes. Kumiho Save Image and Kumiho Save Video both have a tags input (comma-separated), and when the SDK is connected they actually call the SDK's revision.tag() for each one and create the revision with that tag attached. So if you want a render tagged approved, put it in the save node's tags field at generation time, not in this node afterwards. The one thing Tag Revision would add - tagging a revision you didn't just make - is exactly the thing that isn't implemented yet.

So what's it good for today? Honestly, close to nothing on the backend side. If you're sketching out a graph where a later release will tag outputs, you can wire it now and know the sockets won't change. Just don't let a row of success: true nodes convince you your cloud is organized.

Install & troubleshooting

Same pack as everything else: ComfyUI Manager → search "Kumiho", or git clone https://github.com/kumihoclouds/kumiho-comfyui into custom_nodes + pip install -r requirements.txt, then pip install kumiho-cli and kumiho-cli login for auth. No models.

There's no meaningful troubleshooting because the node can't fail - which is the whole warning. Verify tagging worked by checking the revision in Kumiho's UI or the tags field that the save node recorded in its metadata, not by trusting this node's output. If you need real tags today, use the save nodes' tags input, and treat Tag Revision as a scaffold waiting for the backend to catch up.