JR H3 Cache Config Router

The JR H3 Cache Config Router answers a genuinely smart question: cache profiles are content-dependent - a dialogue-heavy scene shouldn't be cached as aggressively as a static wide shot - so why should a human pick the profile? This node reads the finished H3 prompt, classifies it, and emits a ready-made cache config that the Adaptive Cache node consumes. It's the "what should I set these twenty cache widgets to" problem, outsourced to an LLM once per prompt instead of your intuition every render.

Like the Prompt Optimizer, it's OpenAI-compatible rather than MiniMax-specific: point api_base_url at any /v1/chat/completions service (default http://127.0.0.1:10000 - your local vLLM/Ollama-style server). It classifies the prompt into a scene type and maps it to versioned local cache presets, then packages the result as a JR_H3_CACHE_CONFIG object. The whole design is built around the hand-off: CacheConfigRouter.cache_config → AdaptiveCache.cache_config, at which point Adaptive Cache's manual widgets are ignored as a group. That's the documented wiring, and it's why the router's selected_profile and analysis string outputs are for display/logging only - you do not need to connect them.

Inputs that matter

• optimized_prompt (required, multiline) - the finished H3 prompt. The classifier is only as good as this text, so feed it the formatted output from the optimizer, not your raw scribble.
• enable - a real bypass; flip it off and the router passes through a safe default.
• API knobs - api_base_url, model (empty = query /v1/models at runtime), api_key, temperature (default 0 - you want this deterministic), top_p, max_tokens, timeout_seconds, disable_reasoning.
• quality_level - Conservative / Balanced / Aggressive, the cache aggression the router is allowed to pick from.
• cache_device + gpu_reserve_mb - inherited into the emitted config.
• audio_content, has_reference_audio, has_reference_video - hints that steer classification (a music-heavy or reference-driven prompt gets different treatment).
• fail_mode - Safe Balanced (default), Disable Cache, or Stop Workflow when the LLM call or classification fails. Safe Balanced keeps you rendering on a reasonable default; Stop Workflow is for when you'd rather know.

Outputs

cache_config (the JR_H3_CACHE_CONFIG you wire into Adaptive Cache), plus selected_profile and analysis strings for the curious.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node
<your-comfyui-python> -m pip install -r ComfyUI_JR_MiniMaxH3Node/requirements.txt

or ComfyUI Manager → search ComfyUI_JR_MiniMaxH3Node. No bundled model - you supply the endpoint.

Troubleshooting

• Config comes out but Adaptive Cache ignores it? Check you connected cache_config to cache_config and left selected_profile/analysis unconnected - those don't drive anything.
• Every run lands on the safe default - the endpoint is likely unreachable (default URL is a local port) or the classification failed. fail_mode: Safe Balanced hides this by design; check the router's analysis output.
• Cache still misses a lot - the router picked a profile, but hits are content-dependent. That's the cache's nature, not a router bug. Check hit counts in the Adaptive Cache log before adjusting.