MiniMax H3 Context IR

If you've ever typed a decent two-sentence video prompt and watched the model produce a camera move you didn't ask for, Context IR is the fix that doesn't require you to become a prompt engineer. It's MiniMax's own prompt-enhancement service - "In-Context Regeneration" from the H3 launch material - exposed as a node. You give it your content and a target length and shape; it gives you back a rewritten prompt built for that specific render.

Notice what it is not: this isn't a local LLM rewriting your text, and it isn't the same thing as the prompt_expansion_mode on the Max nodes. It's a hosted task with its own endpoint, which is why it has a task_id and a status - there's a real job behind it.

How it works

The node posts to MiniMax's /v2/h3_context_ir endpoint with your content, a duration and a ratio, then polls the task the same way the generation nodes do. What comes back is more interesting than a string: besides enhanced_prompt, it emits enhanced_content - a MINIMAX_H3_CONTENT value that is your original content with the text item swapped for the enhanced prompt. Your frames, reference images, videos and audio pass through untouched, roles intact.

That's the neat part of the design. You can insert Context IR between Content Builder and any generator that supports it and nothing else in the graph changes, because the wire types still match.

Inputs and outputs

Required is content (from Content Builder) plus duration (4–15) and ratio (the usual seven). The duration and ratio aren't decoration - they tell the enhancer what it's writing toward, so a 5-second 9:16 clip gets a different rewrite than a 15-second 21:9 one. Same ratio rule as everywhere else: text-only content can't be adaptive, and frames force the enhancer toward adaptive.

The outputs are enhanced_prompt (the plain string, handy for a text display or for logging what you actually rendered), enhanced_content (wire this one onward), task_id, status and task_json. Keep task_id if you want to look the job up later - it shows up in task listings as task type h3_context_ir, which is a handy way to audit how much you're spending on rewrites.

Where it fits, and where it doesn't

Use it when your prompts are short and the output keeps drifting from your intent - this is the cheapest way to close that gap, because a rewrite costs far less than a bad render. It's the same instinct as running a prompt through an LLM before you sample, which the local crowd does constantly; the difference is that here the enhancer is the company that owns the renderer.

Where it doesn't fit: the Max and Max Turbo models don't use H3-Context-IR at all, and Fast doesn't support it. The pack's README is explicit about that - Max has its own prompt_expansion_mode instead. So if you're on a Max workflow, reach for that widget rather than this node.

And don't chain it in a loop you run twenty times a day. Each call is a round trip to a hosted service; you're paying in latency at minimum, and in the polite sense of not hammering someone else's API. Enhance once, read the result, and if you like it, paste it in as a literal prompt.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/magicwang1111/ComfyUI-MiniMax-H3-API

Restart ComfyUI, then cp local.example.json local.json inside the pack and add your MiniMax key, with base_url set to the region your key belongs to (https://api.minimax.cn or https://api.minimax.io). Only requests and Pillow are installed - no model files. ComfyUI Manager: search ComfyUI-MiniMax-H3-API.

If it fails

The usual two first: missing local.json, and a key from the wrong region pointed at the wrong endpoint. Past that, a failure here is a task failure, so task_json is where the reason lives - the node raises with the API's own error message rather than swallowing it.

One behaviour worth expecting: cancellation propagates oddly. If you use Cancel Delete Task on a Context IR job, the poller sees a terminal status that isn't success and raises, rather than returning an empty prompt.