Load Latent Batch MXD
Resume every WAN 2.2 run in a folder, one after another
- shift
- positive
- negative
- samples
- steps
- cfg
- sampler_name
- scheduler
- end_at_step
- filename_prefix
- trim_latent
Load Latent I2V MXD resumes one saved WAN 2.2 run. Load Latent Batch I2V MXD is that same node pointed at an entire folder: it loads every .latent in a subfolder of input/latents and returns the full bundle - latent, conditioning, sampler settings - as lists, one set per file, aligned by position. If you queued a batch of first-stage generations overnight, this is the node that lets you finish them all without touching a dropdown twenty times.
What you get
subfolder- the folder underinput/latentsto scan.samples(list) - every latent, in order.positive/negative(lists) - each file's conditioning.steps,cfg,sampler_name,scheduler,end_at_step,shift(lists) - each file's restored sampler settings.filename_prefix(list) - each file's derived save prefix.
Everything is indexed: samples[2] matches positive[2], cfg[2], scheduler[2], and so on. Feed these lists into a list-capable sampler loop and every saved run gets finished with the settings it was originally created with. That index alignment is the entire value proposition - in a batch of saved runs, each one carries its own parameters, and this node keeps them strapped together.
When you'd reach for it
The batch-resume pattern: run a folder's worth of first stages, save them all, then finish them in a single pass. It's also the natural partner for anything that generates many saved latents in a loop - the folder becomes the queue, and this node drains it. For a single file you'd use the non-batch loader; this one exists precisely for the "I have a pile of these" moment.
Gotchas
- The list outputs are the contract - your downstream sampler must accept lists (a list-aware loop, not a plain KSampler) or you'll be back to one-by-one wiring.
- Every file must be a complete save (
.latent+.cond.pt). Missing sidecars mean missing conditioning for that entry, and a partially-formed batch is a debugging headache. - Same WAN 2.2 conventions as the single loader: files live under
input/latents, and it's tuned for the pack's save format.
Install
ComfyUI Manager → search Maxed Out → install → restart, or:
cd ComfyUI/custom_nodes
git clone https://github.com/Maxed-Out-99/ComfyUI-MaxedOut
No requirements.txt, no model downloads. Under MXD/Latents (I2V), right beside the single-file version. If the batch save side of this pack is how you scale up generation, this is the node that scales up the finish too.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| subfolder | COMBO | 1 options: |
Outputs (11)
| Name | Type | Description |
|---|---|---|
| shift | FLOAT | — |
| positive | CONDITIONING | — |
| negative | CONDITIONING | — |
| samples | LATENT | — |
| steps | INT | — |
| cfg | FLOAT | — |
| sampler_name | euler,euler_cfg_pp,euler_ancestral,euler_ancestral_cfg_pp,heun,heunpp2,exp_heun_2_x0,exp_heun_2_x0_sde,dpm_2,dpm_2_ancestral,lms,dpm_fast,dpm_adaptive,dpmpp_2s_ancestral,dpmpp_2s_ancestral_cfg_pp,dpmpp_sde,dpmpp_sde_gpu,dpmpp_2m,dpmpp_2m_cfg_pp,dpmpp_2m_sde,dpmpp_2m_sde_gpu,dpmpp_2m_sde_heun,dpmpp_2m_sde_heun_gpu,dpmpp_3m_sde,dpmpp_3m_sde_gpu,ddpm,lcm,ipndm,ipndm_v,deis,res_multistep,res_multistep_cfg_pp,res_multistep_ancestral,res_multistep_ancestral_cfg_pp,gradient_estimation,gradient_estimation_cfg_pp,er_sde,seeds_2,seeds_3,sa_solver,sa_solver_pece,ddim,uni_pc,uni_pc_bh2 | — |
| scheduler | simple,sgm_uniform,karras,exponential,ddim_uniform,beta,normal,linear_quadratic,kl_optimal | — |
| end_at_step | INT | — |
| filename_prefix | STRING | — |
| trim_latent | INT | — |