TF Load Levels

TF Save Levels writes trajectories to disk; this is the node that brings them back. TF Load Levels reads a .npz from output/trajectory_forcing/ and hands you the exact trajectory that was saved - all four latent levels, plus the class, seed, and edit history - as a live TF_LEVELS socket. It's the "reuse the GPU time you already spent" node, and it's what makes a comparison across a restart or between two different workflows mean anything.

The input that trips people is file, a dropdown of the .npz files under output/trajectory_forcing/. It's built when ComfyUI sends its node definitions, so a file you saved after the page loaded won't be listed until you refresh - the tooltip is blunt about it: "press R." The escape hatch is path_override: paste an absolute path to a .npz anywhere on disk and it bypasses the dropdown entirely, which is how you load a trajectory that lives outside the standard output folder or was moved between machines. Outputs are levels (the restored trajectory) and info (its provenance - class, seed, and history, so you can confirm this is the run you think it is before you build an experiment on it).

The one thing a loaded trajectory lacks is a pipeline. The pack's invariant is that a trajectory carries the pipeline that made it, and a restored one has none - so this is the single case where you wire pipeline explicitly into whichever node needs to sample or decode it (TF Resume From Level, TF Decode Levels, TF Latent Preview with a decode). Everything that only reads latents - TF Compare Levels (latent mode), TF Levels Info, TF Region Map, the token tools - works on a loaded trajectory with no extra wiring at all.

A couple of grounded details worth knowing. Loading is pure file IO plus a little numpy, so it's effectively instant - no model load, no GPU work. And the restored trajectory faithfully reproduces the state you saved, including whether it was dirty (edited but never resumed), because the save format carries dirty_level too. That means you can save mid-edit and resume the thought later, which is a workflow the pack's design explicitly supports rather than an accident.

The failure mode to watch for is version drift: a .npz written by a different pack version, or a trajectory whose grid or level count doesn't match what the loaded pipeline expects, will produce confusing downstream errors rather than a friendly message. If that happens, check TF Levels Info on the loaded trajectory against the pipeline's info from TF Load Pipeline - the two should agree on shape before you start editing. Keep saved baselines named well and they'll still be loadable long after the ComfyUI session that made them is gone.

Install

Pack-standard: Manager → search Trajectory Forcing, or git clone https://github.com/korayulusan/ComfyUI-TrajectoryForcing into custom_nodes/. The pack runs JAX inside ComfyUI and wants its own Python 3.11 environment on CUDA 12; requirements.txt is empty on purpose, install.py adds the JAX stack or declines with a reason (normal), and README's env/setup.sh is the fallback. Health check:

cd ComfyUI/custom_nodes/ComfyUI-TrajectoryForcing
python -m tf_nodes.doctor

If you're loading a saved trajectory to re-run an experiment, also re-import TFSaveReport and TFSaveImages from the original run - matching the new numbers to the old provenance is what makes the second run a comparison instead of a coincidence.