🦊 Kumiho Get Dependencies

Kumiho Get Dependencies is the node that's supposed to answer the most useful question in a versioned asset system: "what does this revision depend on, all the way down?" The answer, in the current release, is {"dependencies": [], "depth": 0} - always, no matter what you feed it. Check the source and you'll find the same TODO: Implement actual Kumiho API integration that's wearing a trench coat in the pack's other graph nodes. The plumbing is all there; the backend call isn't.

When it does ship, here's what you're getting. revision_kref names the revision to traverse, max_depth controls how many hops down the dependency tree you go (1–20, default 5 - this is the knob for the "impact analysis" the README brags about, and the thing that will keep your queries from exploding on a big graph), and edge_types lets you filter which relationship kinds to follow as comma-separated names like USED_MODEL,USED_LORA. Out comes dependencies_json, a STRING you'd feed into anything that wants a JSON blob - a viewer, a logger, or a node that turns it into a human-readable summary. That's the whole interface, and it's a sensible one.

Here's the important part for people actually building workflows: the dependency data you want already exists today - it's just in a different socket. The Kumiho Save nodes build the full picture at save time. Kumiho Save Image and Kumiho Save Video each emit lineage_json, and that's a real, populated record: every detected dependency (model, LoRA, VAE, ControlNet, input image) with its kref, the edge type drawn to it, the seeds, the generation settings, and the stored workflow. If you want to know what a render depended on, read lineage_json off the save node that produced it. Kumiho Load Asset also returns a metadata JSON on the load side, so there's a reference-shaped answer available both upstream and downstream - just not through this node.

What Get Dependencies uniquely promises is the reverse traversal: given a dependency (say, a model you're about to retire), find everything that depends on it, recursively, so you can see what breaks before you touch it. That's the classic "impact analysis" use case and it is genuinely not available yet. If that feature is why you're here, this pack is an early-stage bet, not a solution - the three graph nodes are scaffolds, the README oversells what they do, and the honest working surface is Load / Save / Search. Keep an eye on the repo for the version where the TODO becomes a real SDK call; until then, treat this node as a placeholder for a dashboard you'll want to wire up when it arrives.

Install & troubleshooting

Same pack: 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. No models.

Troubleshooting is one line: if dependencies_json comes back as an empty list no matter what kref you enter, you're not doing it wrong - the node is. Verify against a save node's lineage_json to confirm your assets actually carry dependencies, and don't build quality gates or "did this change anything" checks on this output until the backend integration lands.