H3 Native MiniMax H3 Adapter

The prompt pipeline's whole job is to produce a string and a set of intentions. Eventually those have to land on actual ComfyUI nodes with actual sockets. This adapter is the thing that spells out where each piece goes - including the parts it deliberately does not carry.

What it does

It takes a rendered context report and emits two things: the exact final prompt, unchanged, and a native_h3_wiring manifest - a description of which native MiniMax H3 conditioning node each admitted asset belongs on, addressed by socket path.

The prompt is preserved byte for byte. That's stated in the node's own contract: "prompt output remains exact and original media stays directly connected to native conditioning." So the adapter doesn't rewrite, shorten or re-encode anything; it tells you where to plug in.

The wiring manifest speaks in pinned, real socket paths. On the image-to-video side those are the first-frame and last-frame inputs of MiniMaxH3ImageToVideo. On the reference side it addresses the indexed sockets of MiniMaxH3ReferenceToVideo - reference images, reference videos, the audio attached to each reference video, and reference audio, each as an indexed child path. That addressing is what lets a manifest describe eleven bindings without a picture.

Why not just copy the string

Because the parts you can't copy are the interesting ones. The prompt is text; your media is a set of live ComfyUI values - an IMAGE tensor, a VIDEO object, an AUDIO object - and they have to be connected directly to the native conditioning node rather than serialised through the prompt chain. Media stays on its own connections, always. The manifest is the pack's way of saying "reference asset-1 goes to the reference-image slot indexed 1, and its soundtrack goes to the audio child of that reference video," without ever carrying the pixels through a typed envelope.

The other reason is authority. A wiring value is issued by the runtime for a specific report, and consumers of it check that pairing. H3 Product Shell Boundary verifies the wiring belongs to the report - a mismatched or stale pair is refused as invalid_authority or stale_wiring. That's how the sidebar can trust what it displays without re-deriving it.

Inputs and outputs

One required input: report (H3_CONTEXT_REPORT), described as the "rendered H3 context report to map to native H3." In practice that's the report from H3 Context Compiler (or from the source-profiled renderer if you're on that route).

Two outputs:

• prompt (H3_PROMPT_STRING) - the final prompt, exact.
• native_h3_wiring (H3_NATIVE_H3_WIRING) - the pinned node and direct-media wiring manifest.

Wire prompt into the text field of your H3 conditioning node, connect your media to the sockets the manifest names, and keep native_h3_wiring for H3 Product Shell Boundary if you're driving the sidebar boundary yourself.

Install

The pack isn't in the Comfy Registry yet:

cd ComfyUI/custom_nodes
git clone https://github.com/rookiestar28/ComfyUI-MiniMaxH3-Studio.git
# restart ComfyUI

No Python dependencies declared, nothing downloaded at install, prebuilt browser extension, Python 3.10+.

This is the node where the pack's relationship with ComfyUI matters, so read the compatibility notes once: the sidebar needs the host to provide the native H3 nodes (MiniMaxH3ImageToVideo, MiniMaxH3ReferenceToVideo), the official video_minimax_h3_* templates, and a frontend with sidebar-extension support. The extension checks what your host actually provides rather than a version number, and if something is missing, it names it. The canvas nodes keep working even when the sidebar can't load - which is precisely the case where you'd be wiring things by hand with this adapter.

You'll also need official MiniMax H3 weights installed for generation. The pack never installs or manages them; the sidebar's App Mode fills loaders from whatever official weights it finds and warns you by name for anything it can't match.

Where it goes wrong

If you're feeding this node a report from a different run - say you swapped the request upstream and reused a cached report - the wiring won't match. The consumers are strict about it, and the failure reads as an authority error rather than a prompt error, which is a hint to look at the graph, not the text.

Second, the manifest describes; it does not connect. A workflow with the adapter in it and nothing wired to the H3 node's conditioning inputs is a valid graph that generates nothing useful. That's a feature of the design - connection is your decision - but it's surprising the first time.

Third: the prompt is exact by design, so any misspelling, missing dialogue or awkward phrase in your plan arrives intact at H3. Fix it upstream, or use H3 Context Audit Override to take deliberate authorship of a change - and have the override on the record while you do it.