LatentCutToBatch

LatentCutToBatch slices a single latent along one of its axes into equal chunks and stacks those chunks onto the batch dimension. One latent in, a batch of smaller latents out - it's the splitting twin of Latent Batch, and it exists for the workflows where a canvas is too big to sample as one piece and has to be tiled.

The three inputs:

• samples - the LATENT to split.
• dim - which axis to cut along: t (time/frames for video latents), x (width), or y (height).
• slice_size (default 1) - how big each chunk is along that axis.

Output is a LATENT whose batch size is now original_size ÷ slice_size, with each item one chunk.

What it's for

The headline use is tiled sampling of very large images. If a latent is too big to denoise in one pass, cut it along x and y into tiles, sample each tile as its own batch item (with the right prompts or denoise per tile), and stitch the results back with the matching composite/batch nodes. Cutting into a batch is the key trick because it lets the sampler process all the tiles in one call instead of one-at-a-time. The same move works on video: cut along the time axis into chunked frame groups, process, rejoin - the frame-chunking pattern people use to extend or handle long clips.

The gotchas that will bite

It silently drops the tail. If the axis isn't a clean multiple of slice_size, the node truncates the remainder rather than erroring - you asked for 9 chunks, got 8, and the last sliver of your latent is just gone. Double-check your numbers before you cut; there's no warning.

Second, the output is a batch, which changes everything downstream. Each chunk becomes a batch item, so nodes that assume one image (decoding, most compositing) will process them as a group - to work with tiles individually you'll be pairing this with Get Latent From Batch. And it does not remember the layout: nothing in the output tells you chunk 3 came from the middle of the top row, so keep the bookkeeping on your side of the graph (or use a node pair designed for tile-then-stitch).

Third, if the axis you cut is shorter than slice_size, the node gives up and passes the latent through unchanged - a silent no-op that's easy to misread as a bug. It ships with ComfyUI core, no install, and it's genuinely useful once you internalize "cut into a batch = one sampler call for all the tiles." Just respect the divisibility rule first.