Chains
Chaining tools
Stack the steps in the order you want them to run, tune each one, and press Run once.
Drop tools into a chain frame in the order you want them to run. The first step takes your input, and every step after it takes what the one above produced. ## Building one 1. **Start from the sequence you already ran by hand.** The settings you tuned on those cards are the settings the chain wants 2. **Add the steps in order.** Position is execution order, so the top row runs first 3. **Set each step's model and settings.** Every step keeps its own model pill and its own gear, exactly as the standalone card would 4. **Check the summed price** on Run before pressing it 5. **Press Run once** The result lands on the canvas the way any single generation does, as one asset from one press. While it runs, the panel under the top bar carries the chain's name and the step it is on, so a four-step chain reads **step 2 of 4** rather than sitting on one number for several minutes. Clicking that row takes the canvas to where the result will land. ## Where the input goes Only the first step takes anything from you. Every step after it is fed by the one above, so the top of the frame is the only place anything goes in. When the first step is a tool that takes a picture or a clip, the frame shows a drop tile above the steps. Drag an image or a video reference onto it from the canvas, or click it to pick a file. The line beside the tile is the first step's own request, so it reads "Drop an image" or "Drop a video" depending on what that tool wants, and it stops asking once the tile is filled. A first step that wants a prompt rather than media is set with its pencil, which opens that tool's card. :::caution[Reordering carries the input with its step] An input belongs to the step you gave it to, not to the top of the stack. Move a configured first step down and its picture goes with it, so whichever step arrives at the top is empty and the chain asks again. ::: <!-- SHOT: a chain frame with the drop tile filled at the top, three steps below it, and Run at the bottom. Caption names the tile as the chain's only input. --> ## Start from something you already made A chain does not have to be built from nothing. Right-click a generated asset and Plnty reads back the tools that made it, offering that sequence as a chain you can point at something else. It lands unsaved and unrun, so nothing is spent until you press Run. What comes back is what was recorded at the time: the tools, their order, their models, their settings, the prompt, and the LoRA a step ran on. Where something was never recorded, the chain names the step that is missing it rather than quietly starting that step from its defaults. :::note[Older work carries less] Plnty records more about a generation now than it used to, and a rebuild can only return what was written down on the day. A sequence from months ago may come back with a step whose settings are its defaults, which the chain will tell you about. ::: ## Step order The order that works is almost always cheap-and-structural first, expensive-and-final last. | Put early | Put late | | - | - | | Generation, which decides what the thing is | Upscaling, which multiplies the cost of everything before it | | Background removal, which changes the composition | Grading and finishing, which only makes sense on the final frame | | Remeshing, which changes the topology everything else sits on | Texture regeneration at 4K or 8K | Upscaling early is the classic expensive mistake. Every step after it works on a bigger image, which usually costs more and always takes longer, and you have paid to enlarge something you were about to change anyway. :::caution[The price is summed, so mistakes multiply] A four-step chain with a flagship model in step one costs what four steps cost. Read the number on Run before the first press rather than after it, especially when you have just swapped a model pill. ::: ## Reordering steps Order is set when you build a chain and is not fixed there. Drag a step by the number on its left: the number becomes a stack handle when you point at it, the row lifts as you carry it, and the list shows where the step will land while you are still moving. Changing the order changes what feeds what, so any results the chain had saved from the moved position onward are cleared. A chain part way through a sequence runs those steps again rather than replaying results that no longer match the order they now sit in. :::note[Some orders will not run] Putting a step that produces a video above one that expects an image leaves a chain Plnty will not compile, and the frame says so under the step that broke it. Run stays inert until you fix it, so an order that cannot work costs nothing to try. ::: ## Change a step's model or settings Each row carries the same controls its card would: the model pill, and the settings behind the gear. Anything you change shows in the grey line under the step's name, so you can see what a row is set to without opening it. Swapping a model inside a chain changes that step's price, and therefore the total. ## Keep steps A chain puts its last step on the canvas and leaves the middle ones off it. They are not discarded. Every step is saved to your [asset library](/docs/using-plnty/the-asset-library/where-your-work-lives/) like any other generation, so the middle of a run stays searchable even when it never appeared on the board. Turn on **Keep steps** and each step's result lands on the canvas as well, in a row beside the chain, in the order they ran. It is off by default and only offered once a chain has more than one step, because the usual case is that the middle is scaffolding. Turn it on when you are still deciding whether the order is right, since seeing what step two handed step three is the fastest way to find the step that is letting the chain down. ## Run it more than once A chain runs once per press and reopens when it is done, which is what you want while you are still working the sequence out. When the sequence is settled and you want several passes of it, lock the chain instead. The padlock in the chain's header keeps the frame open through a run and gathers every result into one frame beside it, instead of leaving them loose on the board. The number next to Run says how many times a single press fires. Raising it above 1 locks the chain for you, because a batch is a locked session rather than a separate mode, and a locked chain keeps its Run button reading which run and which step it is on. Runs go one after another rather than all at once. A chain is several paid steps, and firing five four-step chains simultaneously would reach the provider's in-flight limit partway through with credits already reserved on the runs behind it. :::caution[The number on Run is the whole batch] Three runs of a four-step chain is twelve steps of credit, and Run shows that total before the first press rather than the price of one pass. ::: A batch stops at the first run that fails instead of firing the rest into the same wall. Whatever landed before it stays, and pressing Run again starts a fresh batch. <!-- SHOT: a locked chain mid-batch, padlock lit, its results filling the frame beside it. Caption reads the run and step off the Run button. --> ## When a step fails The chain runs as one operation, so a failure part way through stops the sequence rather than delivering something half-processed. The frame names the step that stopped it. Every step that finished before it is kept and pinned, so running the chain again pays only for what did not happen. The furthest of them also lands on the canvas, which gives a stopped run something to carry on from instead of leaving you to go looking for it. The failure reports the same way any run does, with a code and a tier telling you whether it was your input, a transient provider problem, or something on our side. See [when a run fails](/docs/using-plnty/using-a-tool/when-a-run-fails/). :::tip[Debug a chain by taking it apart] When a chain keeps producing something wrong, run the steps as individual cards once. A step in isolation shows you its own output, which is usually enough to tell a bad setting from a bad order. ::: ## Interrupted runs Refreshing the page or closing the tab mid-run is not the same as a failure. The steps themselves run on our servers and carry on finishing there. What stops is the part in your browser that starts the next one. Reopen the board and the chain picks itself back up. Before it continues it checks what became of the step that was in flight when you left, because that is the one it has no record of: | What it finds | What happens | | - | - | | The step finished while you were away | Its result is kept, and the chain continues from the next step | | The step is still running | The chain waits for it rather than starting it again | | The step failed | The chain stops there and names it | **You are not charged twice for a step that already finished.** That is what the check is for: a chain restarting from the last step it saw finish would re-run one the provider had already completed and billed for. Only the browser that started the run picks it up. A collaborator opening the same board is not made to finish somebody else's work, and neither are you on a different machine. A run abandoned more than about six hours ago is left where it is, on the grounds that it is not one you are still waiting on. ## Saving one to reuse A chain you have got right can be saved instead of rebuilt. [Reusing a chain](/docs/using-plnty/chains/reusing-a-chain/) covers how.Drop tools into a chain frame in the order you want them to run. The first step takes your input, and every step after it takes what the one above produced.
Building one
Section titled “Building one”- Start from the sequence you already ran by hand. The settings you tuned on those cards are the settings the chain wants
- Add the steps in order. Position is execution order, so the top row runs first
- Set each step’s model and settings. Every step keeps its own model pill and its own gear, exactly as the standalone card would
- Check the summed price on Run before pressing it
- Press Run once
The result lands on the canvas the way any single generation does, as one asset from one press.
While it runs, the panel under the top bar carries the chain’s name and the step it is on, so a four-step chain reads step 2 of 4 rather than sitting on one number for several minutes. Clicking that row takes the canvas to where the result will land.
Where the input goes
Section titled “Where the input goes”Only the first step takes anything from you. Every step after it is fed by the one above, so the top of the frame is the only place anything goes in.
When the first step is a tool that takes a picture or a clip, the frame shows a drop tile above the steps. Drag an image or a video reference onto it from the canvas, or click it to pick a file. The line beside the tile is the first step’s own request, so it reads “Drop an image” or “Drop a video” depending on what that tool wants, and it stops asking once the tile is filled. A first step that wants a prompt rather than media is set with its pencil, which opens that tool’s card.
Start from something you already made
Section titled “Start from something you already made”A chain does not have to be built from nothing. Right-click a generated asset and Plnty reads back the tools that made it, offering that sequence as a chain you can point at something else. It lands unsaved and unrun, so nothing is spent until you press Run.
What comes back is what was recorded at the time: the tools, their order, their models, their settings, the prompt, and the LoRA a step ran on. Where something was never recorded, the chain names the step that is missing it rather than quietly starting that step from its defaults.
Step order
Section titled “Step order”The order that works is almost always cheap-and-structural first, expensive-and-final last.
| Put early | Put late |
|---|---|
| Generation, which decides what the thing is | Upscaling, which multiplies the cost of everything before it |
| Background removal, which changes the composition | Grading and finishing, which only makes sense on the final frame |
| Remeshing, which changes the topology everything else sits on | Texture regeneration at 4K or 8K |
Upscaling early is the classic expensive mistake. Every step after it works on a bigger image, which usually costs more and always takes longer, and you have paid to enlarge something you were about to change anyway.
Reordering steps
Section titled “Reordering steps”Order is set when you build a chain and is not fixed there. Drag a step by the number on its left: the number becomes a stack handle when you point at it, the row lifts as you carry it, and the list shows where the step will land while you are still moving.
Changing the order changes what feeds what, so any results the chain had saved from the moved position onward are cleared. A chain part way through a sequence runs those steps again rather than replaying results that no longer match the order they now sit in.
Change a step’s model or settings
Section titled “Change a step’s model or settings”Each row carries the same controls its card would: the model pill, and the settings behind the gear. Anything you change shows in the grey line under the step’s name, so you can see what a row is set to without opening it. Swapping a model inside a chain changes that step’s price, and therefore the total.
Keep steps
Section titled “Keep steps”A chain puts its last step on the canvas and leaves the middle ones off it. They are not discarded. Every step is saved to your asset library like any other generation, so the middle of a run stays searchable even when it never appeared on the board.
Turn on Keep steps and each step’s result lands on the canvas as well, in a row beside the chain, in the order they ran.
It is off by default and only offered once a chain has more than one step, because the usual case is that the middle is scaffolding. Turn it on when you are still deciding whether the order is right, since seeing what step two handed step three is the fastest way to find the step that is letting the chain down.
Run it more than once
Section titled “Run it more than once”A chain runs once per press and reopens when it is done, which is what you want while you are still working the sequence out. When the sequence is settled and you want several passes of it, lock the chain instead.
The padlock in the chain’s header keeps the frame open through a run and gathers every result into one frame beside it, instead of leaving them loose on the board. The number next to Run says how many times a single press fires. Raising it above 1 locks the chain for you, because a batch is a locked session rather than a separate mode, and a locked chain keeps its Run button reading which run and which step it is on.
Runs go one after another rather than all at once. A chain is several paid steps, and firing five four-step chains simultaneously would reach the provider’s in-flight limit partway through with credits already reserved on the runs behind it.
A batch stops at the first run that fails instead of firing the rest into the same wall. Whatever landed before it stays, and pressing Run again starts a fresh batch.
When a step fails
Section titled “When a step fails”The chain runs as one operation, so a failure part way through stops the sequence rather than delivering something half-processed. The frame names the step that stopped it.
Every step that finished before it is kept and pinned, so running the chain again pays only for what did not happen. The furthest of them also lands on the canvas, which gives a stopped run something to carry on from instead of leaving you to go looking for it.
The failure reports the same way any run does, with a code and a tier telling you whether it was your input, a transient provider problem, or something on our side. See when a run fails.
Interrupted runs
Section titled “Interrupted runs”Refreshing the page or closing the tab mid-run is not the same as a failure. The steps themselves run on our servers and carry on finishing there. What stops is the part in your browser that starts the next one.
Reopen the board and the chain picks itself back up. Before it continues it checks what became of the step that was in flight when you left, because that is the one it has no record of:
| What it finds | What happens |
|---|---|
| The step finished while you were away | Its result is kept, and the chain continues from the next step |
| The step is still running | The chain waits for it rather than starting it again |
| The step failed | The chain stops there and names it |
You are not charged twice for a step that already finished. That is what the check is for: a chain restarting from the last step it saw finish would re-run one the provider had already completed and billed for.
Only the browser that started the run picks it up. A collaborator opening the same board is not made to finish somebody else’s work, and neither are you on a different machine. A run abandoned more than about six hours ago is left where it is, on the grounds that it is not one you are still waiting on.
Saving one to reuse
Section titled “Saving one to reuse”A chain you have got right can be saved instead of rebuilt. Reusing a chain covers how.