MiniMax-H3 Rewriter Options

The one options node that feeds half this pack

By pytraveler·Created about a month ago·Updated a day ago· 170

options

◄max_new_tokens2048►

◄temperature0.70►

◄top_p0.80►

◄top_k20►

◄repetition_penalty1.05►

◄attn_implementationsdpa►

◄adapterlightx2v/MiniMax-H3-Prompt-Rewriter-LoRA►

◄use_loratrue►

◄merge_loraauto►

◄auto_downloadtrue►

◄gpu_layers-1►

◄n_ctx8192►

◄gguf_runtimeauto►

◄deviceauto►

◄llama_backendauto►

◄trust_remote_codefalse►

◄prompt_fileglobal►

◄self_checkwarnings and notes►

◄fix_oncefalse►

◄downloaderbuilt-in►

Most of the pack's nodes take an options input that accepts this node's single output. That's the whole design: the rewriters, writers and captioners keep a clean front panel, and everything you touch once a month lives here. Leave it unconnected and every node falls back to the decoding parameters the adapter was published with - which is the correct default for almost everyone.

So the honest advice is: don't connect it until you have a reason. When you do, here's what you're getting.

The decoding knobs

max_new_tokens (2048), temperature (0.7), top_p (0.8), top_k (20), repetition_penalty (1.05) - sampling parameters, used only when greedy is off on the main node. If a writer comes back missing a field, lowering temperature is the first thing to try.
attn_implementation - sdpa default; eager or flash_attention_2 if you have it. Non-GGUF models only.

The model-management ones

adapter - which build of the LoRA to apply. The default entry (lightx2v/MiniMax-H3-Prompt-Rewriter-LoRA) means whichever build the model list names for the base you picked - PEFT adapter for a Transformers base, the catalog's GGUF for a GGUF one, the 8B adapter on the 8B node. Below it sit the published precisions: F16 and Q8_0 for each LoRA. The Q8_0 is half the download and rewrites the same - if you're on the GGUF route and never picked this up, that's a free gigabyte or two back. Any .gguf LoRA you drop into models/LLM appears here as on disk:.
use_lora - on by default. Turn it off to run the plain base model, which is the "what's the LoRA actually doing?" experiment.
auto_download - fetch missing weights. Turn it off to fail loudly instead of downloading 52 GB by surprise.
gpu_layers / n_ctx - GGUF only. gpu_layers of -1 is all of them; lower it to fit a smaller card at the cost of speed. n_ctx (8192) is the context llama.cpp allocates - the writer nodes raise it themselves, so this is mostly a rewriter-league knob.
gguf_runtime - auto uses llama-cpp-python if it's importable and the official llama.cpp binaries otherwise. Force llama.cpp when an installed wheel is broken; force llama-cpp-python to keep the model resident between runs (the binaries can't).
llama_backend - which official binary build to fetch: auto → Vulkan (34 MB, about half CUDA throughput), cuda (511 MB, ~2× faster, Windows only - upstream publishes no Linux CUDA build), or cpu. An llama.cpp you already have is run as-is and this stops mattering.
device - auto, cpu, or a cuda:N per GPU. Give the language model a second card and keep_model_loaded becomes worth switching on - nothing has to be evicted to make room. A device the machine doesn't have is refused, not quietly demoted.
trust_remote_code - off, and should stay off. A Transformers checkpoint can ship its own Python, loaded and run with your user's rights; off means such a model is refused rather than executed. Turn it on only for a model you picked and trust - not because a downloaded workflow asked for it.

Where people get burned

The adapter field is what a downloaded workflow gets a say in. Two things to know: a network path (\\host\share\...) is refused outright, because merely looking at one is an authentication attempt against that host. And a swapped LoRA is invisible - the node still runs and fills every field, it just writes something else - which is why the applied adapter is logged to the console every run.
llama-cpp-python CUDA wheels are a trap. Both current ones fail on ordinary consumer hardware (one needs AVX-512 that consumer Intel doesn't have; the other refuses modern RTX cards). The official llama.cpp release archives carry 14 CPU backend variants and native SASS, which is why the same model runs fine as a subprocess where the wheel dies. If you want the in-process backend, the Vulkan wheel is the one that works.
gguf_runtime and llama_backend answer different questions. One picks what runs the model; the other picks which build to fetch and only applies when the binaries are in use. They're both in this node because they're both GGUF concerns, but they're not the same knob.

It's the least glamorous node in the pack and the one that saves you the most pain once you know it's there.

CategoryMiniMax-H3

Inputs (20)

Name	Type	Default	Description
max_new_tokens	INT	204864–16384	—
temperature	FLOAT	0.700–2	—
top_p	FLOAT	0.800–1	—
top_k	INT	200–200	—
repetition_penalty	FLOAT	1.051–2	—
attn_implementation	COMBO	sdpa	Non-GGUF models only.
adapteropt	COMBO	lightx2v/MiniMax-H3-Prompt-Rewriter-LoRA	Which build of the prompt-rewriter LoRA to use. The first entry means whichever one the model list names for the base model you picked. Below it are the published precisions - F16 and the smaller Q8_0, which rewrites the same and halves the download - and any '.gguf' adapter already in your ComfyUI model folders.
use_loraopt	BOOLEAN	true	Turn off to run the plain Qwen3.6-27B baseline.
merge_loraopt	COMBO	auto	Fold the adapter into the base weights once at load, rather than running it as its own matmuls on every token. Measured on Qwen3-VL-8B: 25 tokens a second against 14. 'auto' merges on an unquantized base, where it costs 0.07 s and nothing else, and leaves the adapter attached on a bitsandbytes 4-bit or 8-bit one, where merging means dequantizing and quantizing back. 'on' merges there too, for about 4.5 s at load and the same speed afterwards. A merged run is not word-for-word the unmerged one at the same seed: folding the adapter in reassociates the arithmetic, so a token here and there comes out different. GGUF is unaffected.
auto_downloadopt	BOOLEAN	true	Fetch missing weights from Hugging Face. Turn off to fail instead.
gpu_layersopt	INT	-1-1–999	GGUF only: layers to put on the GPU. -1 is all of them; lower it to fit a smaller card, at the cost of speed.
n_ctxopt	INT	81922048–131072	GGUF only: context size llama.cpp allocates.
gguf_runtimeopt	COMBO	auto	GGUF only: what runs the model. 'auto' uses llama-cpp-python when it is importable and the official llama.cpp binaries otherwise. Force 'llama.cpp' if an installed wheel is broken; force 'llama-cpp-python' to keep the model resident between runs, which the binaries cannot do.
deviceopt	COMBO	auto	Which device the language model runs on. 'auto' behaves as before. Pick a second card and two things change: the model no longer competes with ComfyUI's own for VRAM, and 'keep_model_loaded' becomes worth turning on, because nothing has to be evicted to make room. No CUDA device is visible to ComfyUI, so only 'cpu' will do anything.
llama_backendopt	COMBO	auto	GGUF only, and only when llama-cpp-python is absent: which official llama.cpp build to fetch. 'auto' takes CUDA on Windows with a supported NVIDIA card (511 MB, about twice as fast) and Vulkan otherwise. Pick 'vulkan' to keep the download at 34 MB. Nothing is fetched at all when llama.cpp is already here: a build on PATH, one named in MINIMAX_H3_LLAMA_BIN, or a path written into user/minimax_h3_rewriter/llama_bin.txt is run as it is -- the file being the one that works when the server's environment is not yours to set. That is the way to a CUDA llama.cpp on Linux, where upstream publishes no CUDA build.
trust_remote_codeopt	BOOLEAN	false	Non-GGUF models only. Some checkpoints ship their own Python and Transformers runs it when the model loads. Off means such a model is refused rather than executed. Turn it on only for a model you picked and trust — not because a downloaded workflow asked for it.
prompt_fileopt	COMBO	global	Which set of saved prompts the nodes connected to this one work in: the file the save dialog writes to and the library window lists. One file is one working set, so a workflow can keep its prompts apart from the rest. The button below makes a new one. The list is read when ComfyUI starts, so a file made by hand needs a browser refresh to appear here -- the same as the model list. Nothing in the run reads this: a prompt already chosen carries its own file name, so the pick keeps working whatever this says.
self_checkopt	COMBO	warnings and notes	How much of the self-check the nodes connected to this one say out loud. Every fresh answer is read back against the rules of MiniMax's own writing guides -- shot numbering and cut times against the duration, dialogue markup, reference tags against what the task takes and what is connected, retention entries, the alignment line. 'warnings and notes' says everything. 'warnings only' drops the guide's softer suggestions, such as the 350-500 word length, and keeps what H3 will likely misread. 'off' says nothing. The reading itself is regexes over text already in memory and costs nothing, so this decides what is reported, not what is looked at -- 'fix_once' keeps working with this off. It does not cover the nodes' own warnings about their inputs, which are about your wiring rather than the model's prose and are always said.
fix_onceopt	BOOLEAN	false	Let the nodes act on what the self-check found, instead of only saying it. Off -- the default -- means the answer you get is exactly what the model wrote. Two things happen when it is on. The alignment line of the frame tasks is a fixed sentence the node already knows, so a model that dropped it simply gets it back: no model, no risk. And for the mechanical findings -- a cut time past the end, an unbalanced <d>, a tag pointing at a reference that is not there -- the writer is asked once more with those findings folded into the prompt as rules. Once, never a loop: a model that ignored a rule twice will ignore it a third time, and every attempt costs a full generation. The re-run is skipped on an answer too broken to rescue, and its result is kept only if it is genuinely better -- otherwise the first answer stands. Whatever happens is said on the node.
downloaderopt	COMBO	built-in	Which code moves the bytes when a model is fetched from Hugging Face. The default is this pack's own transfer, which needs nothing installed and pulls one ranged connection at a time. 'huggingface_hub' is worth picking for the large weights. The Comfy-Org repositories are Xet-backed, and with 'hf_xet' installed the chunks of a single file come down over many connections at once -- the difference between an evening and a coffee on a 30 GB model. Neither package is a dependency of this pack: install them into ComfyUI's own Python, and if they are not importable the built-in transfer runs instead and says so on the node. Nothing fails. It covers Hugging Face repositories only -- base models, GGUF writers, LoRA adapters, a model and its projector. The llama.cpp binaries come from GitHub releases and the two writing guides are one small request each; neither goes through this. Half-finished files are not interchangeable between the two. The built-in transfer parks bytes in '<name>.part' beside the file, huggingface_hub parks them under '.cache/huggingface' inside the folder. Switching in the middle of a download restarts that one file and leaves the other's leftovers behind to delete by hand. A file that is already complete is never fetched twice either way. Cancelling stops between files at once; inside a file it can take a moment on the Xet path.

Outputs (1)

Name	Type	Description
options	H3_REWRITER_OPTIONS	—