Take from Last Time

This is the reading half of the Save for Next Time / Take from Last Time pair, and it's the half that makes "start from what I made last time" loops actually work. On a new queue run, Take from Last Time reaches into a named slot under output/for_next_time/, pulls the saved entry, and hands it back as typed outputs - image, mask, text, audio, video, or latent, whichever the entry holds.

Where it earns its keep: you saved the last frame, its prompt, and its latent at the end of run one. Now run two loads them back, feeds the frame and prompt into an img2img or video-to-video pass, and you've built an iteration loop with zero manual file loading. Combined with Save for Next Time, it's the closest ComfyUI gets to a native "continue from previous" without a custom script.

How it works

slot_name must match the one you used on Save for Next Time - same name, same folder. Then two ways to pick which entry:

• steps_back - 0 is the most recent save, 1 the one before it, and so on. Defaults to 0, which is what you want 95% of the time.
• entry_name - an exact entry folder name or a unique prefix of one. This overrides steps_back when filled in. It's how you pin a specific render instead of "the newest."

The clever bit is the fallback_mode and the blocked-socket behavior. When the slot is empty or steps_back runs past the end:

• block (default) - the sockets with no data are blocked (via ExecutionBlocker), so only the branches that need the missing member get skipped and the rest of the graph runs normally.
• empty - returns blank values.
• error - stops with an error, loudly.

So a slot holding only an image leaves text, audio, video, latent and mask blocked while image flows. That's the "sockets the saved entry holds no data for are blocked" behavior from the description, and it's the difference between a graph that degrades gracefully and one that hard-crashes on a missing member.

There's also a fallback_image input - a seed image that fills the image output whenever there's no saved image. The node description calls this the way to "start a loop from a cleared slot": wire a seed frame in, and the first run of a brand-new loop has something to work from instead of blocking.

Outputs

Six typed data outputs (image, mask, text, audio, video, latent) plus three that always report no matter what: entry_name (which entry was read, empty if none), found (BOOLEAN - true when an entry was read), and entry_count (how many entries the slot holds right now). Those three are your branch conditions: found is the honest way to decide whether to run the loop's "we have history" path or the "seed fallback" path.

Gotchas

The same one as its sibling: Save and Take on the same slot in the same prompt isn't supported - ComfyUI doesn't order two unconnected nodes, so the pair is for consecutive runs. Also, video entries are full copies of the file, so entry_count climbing with every run means disk climbing too; that's controlled by max_entries on the Save side, not here.

Install

Part of the TrentNodes pack (TrentHunter82/TrentNodes):

# ComfyUI Manager: search "Trent Nodes"

# or:
cd ComfyUI/custom_nodes
git clone https://github.com/TrentHunter82/TrentNodes.git
cd TrentNodes && pip install -r requirements.txt

No extra deps. The pair is one of the more quietly impressive things in this pack - it's not flashy, but it changes how you can structure multi-run work.