Build a Minimal Text-to-Image Workflow

Reading someone else's graph teaches you what the nodes are. Building one from an empty canvas teaches you why they are connected that way, and it takes about ten minutes. After doing it once, every downloaded workflow becomes legible, because you can see your own spine inside it.

The seven nodes, and why each one exists

Place them in this order, wiring as you go:

Load Checkpoint brings in the model. It outputs three things: the model itself, a text encoder, and usually a VAE. Those three outputs feed three different parts of the graph, which is the first thing that surprises people.

Two text encoders. One for the positive prompt, one for the negative. They are separate nodes, not one field, and each takes the text encoder output from the checkpoint. Duplicating the node and changing the text is the normal way to create the second one.

Empty Latent Image is the canvas. Its width and height set the output resolution, and batch size sets how many images you generate at once. Keep the dimensions inside the model's native range — for most current checkpoints that means roughly a megapixel of total area, arranged in whatever aspect ratio you need.

KSampler is the engine. It takes four inputs: the model, positive conditioning, negative conditioning, and the latent. Getting positive and negative the right way round matters, and swapping them is the single most common wiring mistake — it produces images that look nothing like the prompt without producing any error.

VAE Decode turns the finished latent into pixels, taking the VAE from the checkpoint.

Save Image writes the result. ComfyUI embeds the entire workflow into the PNG, so the saved file is also a saved graph.

Run it. If you get an image, you have the spine. Everything else in ComfyUI — ControlNet, LoRAs, upscalers, inpainting — is this spine with extra nodes inserted between existing connections.

Measure the sampler settings rather than copying them

Every tutorial gives you numbers. The numbers are model-specific, and the reason to measure them yourself is that you learn what direction to move when something is wrong.

Steps is how many denoising iterations run. More steps means more refinement up to a point of diminishing return, and past that point you are spending time for nothing. Find your model's point by generating the same seed at several step counts and looking for where the images stop changing.

CFG scale controls how strictly the sampler follows the prompt. Low values wander and look soft; high values are literal, over-saturated, and increasingly damaged. The usable window is narrower than people expect and differs by model family.

Sampler and scheduler determine the denoising algorithm. Some converge in few steps, some need more but produce different character. This is the setting where copying a recommendation is most defensible, because the differences are subtle and the interactions with step count are not obvious.

Denoise stays at full for text-to-image. It becomes the important dial only when a real image is the input.

Seed selects which noise you start from. Fix it while testing anything else; randomise it when exploring.

Run the sweep once per model, save the contact sheet, and you will not need to ask again.

Practice: build it, then break it deliberately

Build the spine from empty. Then make these four changes one at a time, restoring between each:

1. Swap the positive and negative connections. Note what the failure looks like — it is worth being able to recognise, because it produces no error message.
2. Set the resolution to twice the model's native dimension in both directions. Observe the duplicated structures.
3. Take CFG well above the usable window. Observe the burnt, over-contrasted result.
4. Drop steps to a handful. Observe the unresolved, mushy output.

These four look distinct once you have produced them intentionally, and recognising them by sight is most of what debugging a graph consists of.

Save the baseline properly

Before extending, save the graph as JSON with a name that includes the model and the date. Keep it somewhere you will not overwrite.

The reason is that extending a graph is where things break, and the fastest recovery is a known-good state rather than an attempt to reason about what you changed. A baseline plus the bypass-based bisection from the debugging lesson turns most breakages into a two-minute problem.

One useful habit: keep a folder of baselines per model rather than one universal baseline. Settings that work for one checkpoint family frequently do not transfer, and having the right starting point is worth more than having a clever graph.

Common mistakes

Editing a template instead of building once. You learn the buttons without learning the structure.

Copying settings across model families. Step counts and CFG windows differ, sometimes substantially.

Not fixing the seed while testing. Every comparison becomes noise, and you learn nothing from the sweep.

Generating far above native resolution. It produces duplicated structures that look like a model defect and are a settings error.