H3 Stage Sampler · ONE Stage + Result (T8 EXP)

Take Core's SamplerCustomAdvanced, add one more required input, and add two more outputs. That's MiniMaxH3StageSamplerEXPT8 in a sentence. The five native inputs and the first two outputs are unchanged - same noise, guider, sampler, sigmas, latent_image, same output and denoised_output - so swapping it in for the Core node doesn't change how the graph samples.

What it adds is stage_context going in, and stage_result plus report_json coming out. That's the whole idea behind the modular sampling family: sample exactly as before, but leave typed evidence behind so the next node - a save, a resume, an audit, a transition - has something better than a hope to work with.

The inputs

• noise, guider, sampler, sigmas, latent_image - plain Core semantics. Note guider specifically, not a conditioning pair: these stages go through a guider, which is what lets the pack's custom samplers and native H3 flow schedule stay in play.
• stage_context - from the matching setup or bind node: MiniMaxH3SPEEDStageSetupEXPT8, MiniMaxH3VDNStageSetupEXPT8, MiniMaxH3RFRestartStageSetupEXPT8, MiniMaxH3RFBaseStageSetupEXPT8, and the rest of the family. It identifies the recipe and the stage, and the sampler uses it to check whether it recognises what it's been handed.

The description is careful about scope: "Runs exactly one native SamplerCustomAdvanced call. No loop, second pass, retry or automatic cache." If you were hoping a "smarter" sampler node would quietly fix an undercooked stage, this isn't that node and never will be - it's an instrumented Core call.

The outputs

• output - Core's returned latent, unchanged.
• denoised_output - Core's returned denoised latent, unchanged.
• stage_result - the typed receipt. Goes to MiniMaxH3StageSaveEXPT8 if you want it on disk, or straight into whatever downstream adapter wants a proven stage (the SPEED transition, the HyperFlow lifts, the continuation routers).
• report_json - includes whether the execution was recognised as a known recipe. Unknown samplers and guiders still execute, but they don't get handed a verified label, which is the honest behaviour: it means a custom sampler from another pack will run, and your later resume will be told it can't promise portability.

That last point is worth internalising, because it's where the family's stricter checks come from. A stage result that can't be authenticated blocks an explicit save or a cold resume from claiming restoration, but it doesn't block generation. The pack would rather refuse to certify a result than invent a cache hit.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Exit ComfyUI completely and restart, then hard-refresh the tab. Manager users: search MiniMax H3 Audio T8 - and install from GitHub if Manager's revision is behind, since the registry and the repo release independently. There is no pip install; the pack deliberately ships an empty requirements.txt so an install can never replace ComfyUI's Torch/CUDA stack. Recent ComfyUI core is required (native H3 support and the newer node API), otherwise everything in the pack shows red.

Models live in models/diffusion_models (H3), models/text_encoders (Qwen3-VL) and models/vae (video + audio VAE).

Gotchas

If you feed a stage_context from one stage and sigmas from another, expect a validation error rather than a creative accident - the sampler checks that the recipe is known before it lets the result be labelled. If you're comparing a split graph against the old all-in-one node and the numbers differ by a hair, check whether you've got an unverified attention override or LoRA on the branch: the pack documents that it won't certify what it can't identify, and it won't pretend two runs are equivalent either.

And the standing hardware note for this family: H3 is a 33B omni-modal model generating picture and sound together. On a 16 GB card, one H3 job at a time - concurrent runs are the fastest way to OOM at startup.