Recipes & the Cookbook

A recipe is an ordered series of operations that produces media. For how recipes, workflows, and models relate, see Models, Workflows & Recipes -- this page covers how recipes work in detail. Recipes capture what works so you can repeat and refine it.

A recipe is not an automated pipeline. You perform each step, inspect the output, and decide when to proceed. AI generation steps may need several runs before the result is satisfying -- a recipe makes that iteration structured rather than freeform.

What a recipe contains

• A name -- what this recipe achieves (e.g. "Character reference sheet")
• One or more steps -- each step performs an operation: a ComfyUI workflow or a built-in operation

Steps

A recipe step is one unit of work. Steps are performed in order, but you control the pace -- each step can be run as many times as needed before moving on.

Each step performs an operation, which is one of two kinds:

• A ComfyUI workflow -- a workflow JSON from your project library or the platform library.
• A built-in operation -- a platform-provided tool such as image crop, resize, or audio merge that doesn't require ComfyUI.

Every step has a category, and you can swap what runs it

A step is described by its category -- what kind of work it does, such as text to image or image to video. Which workflow (and therefore which model) performs it is a choice, shown as a dropdown on the step itself.

Open that dropdown and you see every operation in the same category that your project can run, including the same workflow paired with each of your enabled models or style LoRAs. Pick a different one and the step keeps its place, its name, and its inputs -- only what runs changes.

This is how you compare models: set up a step once, then run it, swap the binding, and run it again. The dropdown always names what is currently selected, so a step never claims to use a model it is not using.

Your input values survive the swap. Anything the new operation has a slot for -- the positive prompt, an input image, the output size -- carries across by name. Values it has no slot for are kept aside and come back if you swap back.

Two levels of inputs

There are two distinct levels of inputs in OA, and understanding the difference matters.

Operation Inputs is the general term for what a step exposes. The specific vocabulary depends on the step type:

• For ComfyUI workflow steps, the underlying inputs are called App Inputs -- named parameters declared using the ComfyUI App builder. Names like "Input Image 1", "Positive Prompt", "Output Width" are App Input names.
• For built-in operation steps, the inputs are the operation's own structured fields.

At the recipe level, both are referred to uniformly as Operation Inputs. Operation Input names are always Title Case.

Step Inputs are the recipe-level abstraction over Operation Inputs. They exist so that recipes can:

• Give inputs friendlier display names (e.g. "Character" instead of "Input Image 1")
• Group related Operation Inputs into one user-facing slot (a single "Prompt" step input covers the two App Inputs "Positive Prompt" and "Negative Prompt")
• Hide system-managed inputs that users should never touch (e.g. "Filename Prefix")
• Link an input to the output of a previous step

One Step Input maps to one or two Operation Inputs. This mapping is called the binding.

Binding types

Binding	Operation Inputs covered	When to use
Direct	One Operation Input (image, audio, video, text, or number)	Most inputs -- a 1:1 connection
Size	"Something Width" + "Something Height"	Paired dimension App Inputs; the step shows a single "Output Size" control
Prompt	"Positive Prompt" + optional "Negative Prompt"	ComfyUI text generation -- one field split by === into the two App Inputs

The split marker for prompts is a line containing only ===. Text above is the positive prompt; text below is the negative. If the workflow has no negative prompt App Input, the negative text is discarded.

What is hidden at the recipe level

Some Operation Inputs exist in the underlying workflow or operation but are never exposed as Step Inputs:

• Filename Prefix -- system-managed; filled automatically from your project context. Users never set it directly.

Step input display names

Each Step Input has a display name -- the label shown to you. This is purely cosmetic: nothing in the system searches, links, or matches by display name. It can be set to something more descriptive than the underlying Operation Input name (e.g. "Character" instead of "Input Image 1").

Linking step inputs to previous step outputs

Each step input can be linked to the output of a previous step. Click on an input's name to open the settings dialog and choose which step output to link to.

The dialog only shows previous steps whose output type is compatible with the input being configured. A Prompt input shows only steps that produce text outputs; an image input shows only steps that produce image outputs. Steps whose output type is unknown are always shown.

When an input is linked and you select an output thumbnail for the earlier step, the value is automatically populated:

• Media inputs (images, audio, video): the linked output file is used as the input file directly.
• Text inputs (including Prompt bindings): the linked output file's text content is read and used as the input value. For .prompt.json files produced by the built-in prompt generator, the positive and negative prompt strings are extracted and placed into the appropriate fields automatically.

For a Prompt binding linked to a .prompt.json file, the positive prompt text is placed above the === separator and the negative prompt below it, matching the format described in the Prompt binding section above.

Because linking operates at the step input level (not the workflow parameter level), a single linked text file can populate both the positive and negative prompt fields in the underlying workflow.

Linking is a convenience, not a constraint. You can still override the value manually before running the step.

When two image inputs hold the same picture

A step with several image inputs -- a compositing step with "Input Image 1" and "Input Image 2", or a video step with a first and last frame -- can end up with the same picture in two of them. This happens quietly: a recipe generated for you may bind one character sheet twice and never bind the location, and the boxes look filled either way.

Whenever that happens, you are told which inputs share the picture -- as soon as the binding appears, and again if you run the step. A run of the whole recipe reports it in the completion summary too, so a long run does not hide it.

It is a warning, not a refusal. Asking a model to blend a picture with itself is almost never what was meant, but the repeat is occasionally deliberate -- holding a first and last frame on one image is how you get a freeze -- so the step still runs if that is what you want.

Step outputs and output labels

When a ComfyUI step completes, output files are automatically routed to the correct media gallery. Each output node in the workflow has an output label -- by default oa. A workflow can have multiple named outputs by declaring multiple Filename Prefix Operation Inputs with labels (e.g. "Filename Prefix #img1", "Filename Prefix #mask"), which produces distinctly-labelled outputs that subsequent steps can target independently.

See ComfyUI Integration for how output routing works.

Finding operations

When you add a step by clicking +, the operation picker shows all available workflows and built-in operations grouped by category (Image to Video, Text to Image, Audio, etc.). A recently used row at the top surfaces the operations you reach for most often.

Filtered to your AI Models

The picker is filtered to your project's AI Models -- the short-list of models chosen for this project (for why you choose models per project, see Models, Workflows & Recipes). Before you have chosen a set, every model is available. Once you have, any workflow whose models are all outside your selection is hidden from the picker. Operations that do not depend on a specific model -- image crop, resize, audio merge, and similar built-in tools -- always appear.

You can adjust the selection from the Actions tab menu (three-dot button in the header) or on the project's AI Models view. The filter only controls what the picker offers -- it does not change how a workflow executes.

Running a recipe

Expanding a step shows its inputs, controls, and -- after running -- its outputs at the bottom. Steps open and close individually; see "Expanding and collapsing" under Editing a recipe below.

Built-in operations (crop, resize, audio merge, etc.) present their controls inline. You perform the operation and save the result. Built-in operations are deterministic, so a single run is usually sufficient.

ComfyUI workflow steps give you two choices before running:

Where to run:

• Local ComfyUI -- runs on your machine via the Chrome extension
• Comfy Cloud -- runs on managed GPU infrastructure

How to run:

• Queue -- submitted asynchronously; OA watches and saves results automatically
• Copy workflow -- copy to clipboard to paste into ComfyUI directly for interactive use

Editing a recipe

A recipe is edited where it runs: load one onto a media gallery's Actions tab and change it there. The Recipes view lists your recipes; it does not edit them.

What you are editing

Each gallery holds one working recipe -- the one currently on its Actions tab. Editing changes that working copy and nothing else: not the recipe in the Cookbook it was loaded from, and not the same recipe loaded on another character, location, prop or shot. There is no save button. Changes are kept as you make them, and a small dot beside the recipe's name marks it as changed since it was loaded. An edited recipe re-enters the Cookbook the way every recipe does -- by producing a result you star.

Start over, at the foot of the step list, wipes the working recipe entirely -- name, steps and all -- after asking. It does not touch anything in the Cookbook.

View mode and edit mode

A recipe opens in view mode. You can fill in inputs, choose which operation each step runs, and run steps, but the names are read-only. The padlock button beside the recipe's name switches to edit mode, which puts the structural affordances on display: a drag handle on every step, and a pencil on the recipe's name, on each step's name, and on each input's name. Renaming anything, and opening an input's settings to link it, are edit-mode actions. Adding and deleting steps work in either mode.

Mode is per visit, not a property of the recipe -- open a recipe again and you are back in view mode.

A recipe is a chain, so order is not decoration

Steps run top to bottom. Each input is either one you fill in or one linked to the output of a step above it: click the input's name in edit mode and choose which earlier step feeds it. That link is what makes a recipe a chain rather than a list -- the second step works on what the first one made.

Two rules follow, and between them they are the reason order matters:

• A link can only point upwards. When you configure an input, the list of sources offers only the steps above it in the recipe.
• Run remaining goes in order. It runs the steps whose outputs no longer match their current inputs, plus everything below them that reads from those, one at a time, top to bottom.

So moving a step above the step whose output it reads, or deleting that step, leaves it with nothing to read at the moment it runs. Nothing is silently rewritten when you reorder -- the link still points at the same step, it is the position that has stopped making sense -- and dragging the step back restores it.

How you can see a chain has come apart

• An input that is fed by an earlier step shows a small link mark beside its name.
• Open that input's settings and the source list shows only the steps now above it. A source you moved below is not offered; if nothing at all sits above the step, the dialog says so and leaves the source fixed at manual.
• Run remaining waits for a linked input to arrive before starting the step that needs it. When it never arrives, the run stops and reports which step did not produce its output in time.

There is no separate warning banner for a broken chain, so if you have reordered heavily it is worth opening the steps that read from others and checking their inputs.

Reordering

In edit mode, drag a step by the handle at the left of its header. The move takes effect immediately. Reordering changes which steps count as "above" for linking, and the order Run remaining works through -- nothing else.

Inserting a step

Hover the gap between two steps, or the gap above the first, and a "+" appears. Clicking it opens the operation picker, and the step you choose lands in that gap; everything below shifts down.

Inserting rewires nothing. If a step was reading the output of the step above it and you insert between the two, it still reads the same step -- now two positions up. The new step joins the chain only when you link one of its inputs to something above it, or link a step below it to its output.

Deleting a step

Delete step is in the step's own menu -- the three-dot button in its header. It always asks first, and when later steps read from the one you are removing, the confirmation names them and tells you their links will be cleared.

Confirm, and those steps keep the value they last received -- it does not vanish from the field -- but they stop receiving a new one. That input goes back to being one you fill in yourself, until you link it somewhere else.

Renaming

A step's name is a label and nothing else. Links point at the step itself, not at what it is called, so renaming never breaks one -- the new name is simply what you will see in the source list the next time you wire something to it. Input values, outputs already produced, and the operation the step runs are all untouched.

Clearing a step's name is allowed: the step then shows the name of whatever operation it runs, and goes on tracking that name if you swap the operation later. A name you typed yourself survives a swap.

The recipe's own name is editable the same way, in edit mode. That renames the working copy; nothing in the Cookbook is renamed with it.

Swapping the operation behind a step

Two routes reach the same place: the operation dropdown inside the expanded step, which offers everything in the same category (described under "Every step has a category, and you can swap what runs it" above), and Replace step in the step's menu, which opens the full operation picker so you can cross categories.

Either way the step keeps its position and its place in the running order. Input values carry across by name, and values the new operation has no slot for are parked and come back if you swap back. The step's name follows the new operation unless you had typed a name yourself.

A swap rebuilds the step's list of inputs from the new operation, so it is worth reopening the step afterwards and checking any input you had linked to an earlier step.

Expanding and collapsing

Steps are independent: the chevron at the left of a step's header opens and closes just that one. A freshly loaded recipe arrives with every step closed, which makes the shape of the recipe easy to read before you start work.

The button beside the padlock acts on all of them at once. It offers "collapse all" only when every step is already open; from any other state -- some open, none open -- it expands them all.

Running a step opens it so you can watch it work, and leaves it open afterwards so you can adjust and run again. Run remaining opens each step as it starts and closes it again as it moves on, unless you had that step open yourself. None of this is remembered between visits.

Asking the Assistant to build one

Describe what you want -- "a recipe that makes a fireworks display: generate an image, then animate it" -- and the Assistant builds it on the gallery you are looking at.

It hands the recipe over filled in, not blank:

• What you said becomes the input. "A fireworks display" is the prompt for the first step, so the Assistant writes it into that step's Prompt box rather than describing it back to you.
• The chain is wired up. The second step's starting image is linked to the first step's output. Linking is its job, not yours.
• You watch each value arrive. The Assistant takes you to the Actions tab, opens the step it is filling in, and the box flashes as the value lands -- the same blue pulse a property change gives. Nothing changes behind your back.
• What it could not fill is named. An input needing a file you have not given it -- the last frame of a first/last-frame pair, say -- is called out by step and input, with the reason. It will not invent a media reference to make a slot look full.

Then it asks whether to run it. It never runs anything until you say yes, and telling it "don't run anything yet" holds for the rest of the conversation. When you do say yes it queues the run and tells you whether it went to Comfy Cloud or to your own ComfyUI, since one spends credits and the other needs your local installation connected.

Everything it wrote is ordinary recipe content: change any of it, run steps yourself, or start over.

Built-in recipes and the Cookbook

Recipes come from two places, and both behave the same way when you run them:

• Built-in recipes ship with the platform, ready to run. You do not edit one in place -- run it, change whatever you want in the gallery, and your version is kept alongside it.
• The Cookbook is your project's own collection, and it fills itself (see below), plus any recipes the assistant has written for you.

The Cookbook learns from what you star

There is no "save recipe" step. Star a result you like, and the recipe that produced it is remembered -- the platform traces that item back through the steps that made it and keeps the chain.

This works the way it does for a reason:

• You never have to decide when a recipe is "finished". The recipe kept is exactly the trail behind the thing you approved. Star a finished clip and you get the whole chain; star a promising still halfway through and you get the part that made it.
• Rejected attempts are not counted. If it took you five goes to get an image you liked, only the run behind the starred image is in the trail. The other four are not.
• Starring the same shape again strengthens it rather than making a second copy. If what you starred matches a built-in recipe, that built-in gets the credit instead of a near-duplicate appearing in your Cookbook.
• Recipes keep the settings worth reusing -- your prompt text, sizes, and the models each step used. They do not keep references to the specific images or files involved, since those belong to that one run.

Each recipe tracks how many runs produced something you starred, so a recipe that needs many attempts per keeper reads as less reliable than one that lands first time.

To change a recipe, run it, adjust whatever you want in the gallery, and star the result -- your version is learnt the same way. You can rename anything in your Cookbook at any time.

Load as Recipe on any gallery item does the same reconstruction on demand: it rebuilds the steps and input configuration that produced that item, so you can inspect or re-run them.

Recipes are always kept in the project. Copying a workflow into your project from a library is the deliberate step; from then on your recipes are built from what your project holds.

See Recipes for the page reference.