TF Levels Info

A Trajectory Forcing levels socket isn't just a stack of latents - it's a small provenance object. It remembers the class it was conditioned on, the seed it was sampled with, and every edit that's been applied to it since. TF Levels Info is the node that reads all that back out, and it's the cheapest sanity check in the pack: wire any trajectory into it and the node body tells you the shape, the class, the seed, and the edit history, with no GPU work at all.

The one thing this node is genuinely for is reproduction. Its outputs exist so you can re-sample what you're looking at: class_id and seed are INTs you can wire straight into TF Generate, which is the pack's own contract for "same seed and class reproduces a trajectory exactly." Say you edit something, decide the edited version is better, and want a fresh trajectory in that same class with a different roll of the dice - wire the original's seed output into a TF Generate and you have a guaranteed-different sample of the same concept. class_name and the info string are there for humans: class 213 means nothing on its own, but "Irish setter" in a writeup does.

The history section is where the node earns its keep during an editing session. A freshly generated trajectory's history is one line: generate(class=213, seed=592). After an edit it shows feature edit: 12 tokens at level 2 <- ... and marks the trajectory dirty - meaning an edit landed but TF Resume From Level hasn't run, so the finer levels above the edit are stale. TF Levels Info says "EDITED at level 2, not yet resumed - levels 3..3 are stale" right in the body. That's the difference between a confusingly half-updated image and a clear instruction to go wire up the resume node. If you've ever spent ten minutes wondering why an edit "did nothing," it's because the node body was telling you the levels above the edit were never re-sampled.

There are no knobs to set - just a levels input and four outputs (info, class_id, class_name, seed). Because everything here is text and metadata, it's also a nice provenance tap for a whole experiment: it's exactly the data TF Save Levels writes to disk and TF Save Images bakes into PNG metadata, so this node shows you what those files will contain before you commit to saving.

Install

Like every node in this pack: Manager → search Trajectory Forcing, or git clone https://github.com/korayulusan/ComfyUI-TrajectoryForcing into ComfyUI/custom_nodes/. The repeated caveat is real - the pack runs a JAX model inside ComfyUI and normally wants its own Python 3.11 environment on CUDA 12 (torch 2.8+), with requirements.txt deliberately empty so Manager can't rewrite the torch your other nodes depend on. install.py either adds the JAX stack or declines with a printed reason; declining is the expected path on most current ComfyUI builds, and the README's env/setup.sh route handles it. When something's ambiguous, ask the pack directly:

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

A trajectory whose history you need to preserve should probably be saved with TF Save Levels anyway - sampling costs GPU time, and the .npz keeps the class, seed, and full edit history so a comparison next week still means something.