Kling AI Element

Kling AI Element packages a Kling "element" ID into a structured object you can pass around your workflow. An element in Kling's world is a reusable asset you've created on the Kling platform - a character, a face, or a style - that you want to reference across generations. Think of it as the Kling equivalent of a reference-image or LoRA handle: you create the element once in Kling's console, and this node wraps its ID so it travels as a single typed value instead of a bare string.

The catch, and I'll be upfront about it: this node is a producer of a KLING_ELEMENT object, and as of v2.1 none of the pack's other nodes consume that object as an input yet. So right now it's a "make the element config explicit" node - useful for keeping your workflow organized and for when you're building toward the Kling endpoints that accept element lists, but not a magic consistency button. If you're chasing character consistency inside ComfyUI, the pack's own routes are the Image Omni node (which takes reference images directly) and the Multi-Shot node (which keeps one subject across shots from a single prompt) - both are more directly wired to generation.

How it works

Two inputs, both simple:

• element_id - the element ID from Kling AI. You get these from the Kling platform (elements you create under your account).
• type - what kind of element it is: character, face, or style. Defaults to character. This matters because Kling treats the three categories differently, and the node needs to know which namespace your ID belongs to.

The single output is KLING_ELEMENT - a small dict holding the ID and type. It's a pure config node: no auth, no API call, no credits, runs locally in microseconds.

When it's actually worth wiring in

• Organization. If you have a stable set of characters or styles you use across many workflows, an Element Selector makes the workflow self-documenting - anyone opening the graph sees a named, typed element rather than a mystery string.
• Future-proofing. The pack evolves quickly (v2.1 added ten nodes); a config node that currently produces a typed object is a reasonable bet that the object will be consumed by a future node. If the element endpoints ever get surfaced as inputs, your workflows are ready.
• Batching with the same ID. If you paste the same element ID into several places, a single selector feeding them all is cleaner than repeating the string.

Common issues

• "Nothing happens when I run it" - correct behavior. This node only emits a config object; it doesn't generate anything. Wire its output somewhere that consumes KLING_ELEMENT, or use it purely as documentation.
• Element not found when you finally use it - Kling elements can be deleted or expire in the console; a stale ID is a string that happens to point at nothing. Verify the element still exists in your Kling account.
• Wrong type - a character ID tagged as a style will be rejected (or silently misused) by whatever endpoint eventually consumes it. Set the type to match where the element came from.

Install

Ships with ComfyUI-Kling-Direct:

cd ComfyUI/custom_nodes
git clone https://github.com/IxMxAMAR/ComfyUI-Kling-Direct

or ComfyUI Manager → search "Kling Direct" → install → restart. No models, no GPU, no extra dependencies. It's a small node with a modest job - and the honest read is that it's more useful as a workflow organizer today than as a generation driver.