H3 doesn't need a permanent sidecar. Model work already happens in a supervised,
per-GPU engine subprocess with its own CUDA context, VRAM manager and swap gate —
so H3 belongs there, registered with the model manager like a Wan or LTX
pipeline, and pinned to a CUDA engine.

What actually forced the worker was the version floor, not the architecture:
diffusers ships H3 as Modular blocks only (0.40+), and this venv is on 0.38.
So the route is now chosen by capability, not hardcoded — engine_supports_h3()
probes for MiniMaxH3ModularPipeline, and `in_process` in the model config forces
either side. The same build works before and after a diffusers upgrade, and the
worker stays as the fallback while H3 is unproven (an in-engine OOM or device
assert poisons the whole engine's context; a subprocess crash doesn't).

_load_h3_pipeline() builds the modular pipeline with ONE workflow (loading with
none pulls both 61.7GB partitions), group-offloads the big modules per component
since a ModularPipeline has no pipeline-level offload helper, and registers it
with record_vram_delta so eviction sees its real footprint. A workflow change
unloads first — the two partitions can't be co-resident.

The checkpoint contracts now live in tools/h3_common.py, loaded by path from the
engine and imported as a sibling module inside the isolated venv, so both routes
snap frames, round the canvas, pick the workflow and mux the audio identically.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY