Stopping and resuming a long workflow run

A twenty-eight scene recipe like Lumee Glow Cat Glow-Up is not a thing you sit and watch. You start it, do something else, and come back. Which means the realistic moment you notice a problem is not before the run and not after it — it is at scene six, with five scenes already rendered and twenty-two still to go.

At that moment there are three things you can do, and most people only know one of them. They cancel and start over, which throws away the five that worked. The other two are cheaper, and picking between them correctly depends on one distinction that is easy to get backwards: stopping a run and resuming a run are not two halves of a pause button.

What you can actually see mid-flight

A run is not opaque while it is going. Asking the agent for the scene breakdown on a run id returns every scene's order, its status, any error message, its timestamps, and a derived "stuck" flag. The status vocabulary is small and closed, and the state machine behind it — plus the ten-minute staleness threshold that drives the stuck flag — is walked through properly in diagnosing a stalled render. What matters for a mid-flight decision is the two things the breakdown gives you beyond a status word.

First, each scene comes back with a trimmed content preview: the scene name, a snippet of its prompt, a snippet of its voiceover, and its caption and overlay counts. So you can tell what scene four was supposed to be without opening the recipe. Second, completed scenes carry their actual image and video URLs. You can watch the first five scenes of a twenty-eight scene run while the sixth is still rendering, which is the difference between suspecting a run has gone wrong and knowing it.

Reading a run costs no credits. It is a status lookup, not a render, so there is no reason to guess. And if you have lost track of which run you started, recent runs are listed with their ids and statuses — up to ten of them — so a run is very rarely actually lost.

Stop is not pause

Here is the part that trips people up.

Stopping a run cancels it. Every scene currently in flight — anything pending, generating an image, or generating video — flips to cancelled so it stops consuming dispatcher time. Completed scenes are left exactly as they are. Provider callbacks that arrive after the cancellation are ignored. Calling stop on a run that has already finished, failed, or been cancelled does nothing.

Resuming a run does something much narrower than the word suggests. It only ever touches a scene that has sat in a generating state past the staleness threshold: it resets the earliest such scene and lets the scheduler carry on from there. It is not a general "continue from wherever this stopped." A scene in any other state is invisible to it.

Put those two together and the consequence is blunt: a run you stopped cannot be resumed. Its scenes are cancelled, and cancelled is not stuck, so there is nothing for resume to find. Stop is a terminal decision, not a hold.

This is why the reflexive "cancel and restart" is worse than it looks. It is not pausing a run to think. It is ending it.

The three interventions, and when each applies

Match the intervention to what is actually wrong, not to how anxious the run makes you.

The run is slow or has gone quiet. Do not stop it. Pull the scene breakdown and look for the stuck flag. If a scene has been in a generating state for more than ten minutes without updating, resume it. If nothing is flagged, the run is working and you are impatient. That is failure-recovery territory rather than a stop-or-continue decision, and it has its own runbook.

A scene failed. A failed scene carries an error message. Read it before doing anything else, because the fix is usually in the scene rather than in the run.

The output is wrong. This is the case this post is really about. The run is healthy, scenes are completing on schedule, and what is coming out is not what you wanted — the character has drifted, the pacing is off, the tone is not the brief. Here stopping is correct, and you should stop early rather than late. On a long recipe like Lunchwell Hospital Visit at eighteen scenes, catching a look problem at scene four instead of scene fourteen is the difference between a small write-off and most of the run.

The one thing to be honest about: stopping does not refund the scenes that already rendered. What it does is stop the ones that have not. That is still the right move when the output is wrong, because every additional scene is spending credits on a video you have already decided not to use.

Salvaging what already rendered

The reason stopping early beats letting a bad run finish is not just the credits you avoid. It is that the completed scenes remain real, finished assets with their own video URLs, and they do not disappear when the run is cancelled.

So a stopped run at scene six leaves you with five rendered clips. Depending on what went wrong, those are worth different things:

If the fault was in a specific scene's prompt, the other completed scenes are still usable. Fix the one scene in the recipe and run again; you now know exactly which scenes hold up.
If the fault was continuity drift, the earliest completed scene is your reference. Whatever it looks like is the look you should be pinning the rest of the run to.
If the fault was structural — wrong order, wrong script, a beat that does not work — the clips may still be usable footage even though the sequence is not. They can be cut against a different order on the editor timeline rather than regenerated.
If a completed scene is nearly right, a still pulled from it is a legitimate starting image for the retake, which is cheaper than re-deriving the look from a prompt.

The mistake is treating a cancelled run as a total write-off. It is a partial render, and partial renders have salvage value.

A mid-flight runbook

Look before you touch. Pull the scene breakdown. Never act on how long it feels like it has been.
Classify. Stuck, failed, or wrong. These have three different answers and only one of them is stop.
If stuck, resume. It no-ops if you were wrong, so the downside of trying is nothing.
If failed, read the error on that specific scene before deciding whether the run or the recipe is at fault.
If wrong, watch the completed scenes first. They are already paid for and they tell you exactly what the fault is.
Then stop, and mean it. Stop is terminal. Do not use it as a pause and expect to pick the run back up.
Fix the recipe, not the run. A cancelled run is history. The next run is where your edit lands.

The agent handles all of the above conversationally rather than requiring you to hold run ids in your head — "why did my run stop", "which scene failed", "cancel that run" all route to the same place, documented at check or resume a stuck workflow run.

FAQ

Can I pause a workflow run and restart it later?

No. Stopping cancels the run and every in-flight scene, and resume only targets scenes stuck in a generating state — a cancelled scene is not stuck, so there is nothing to resume. Treat stop as terminal and plan around it.

Does resuming a run re-charge the scenes that already completed?

No. Resume resets the earliest genuinely stuck scene back to pending and lets the scheduler continue from there. Completed scenes are left alone and are not regenerated. Checking status costs no credits either, since it is a lookup rather than a render.

Do I lose the scenes that finished before I cancelled?

No. Completed scenes keep their image and video URLs and are left intact by a cancellation. They are usable as footage, as continuity references, or as source frames for a retake, which is the main reason stopping early is better than letting a bad run finish.

Should I stop a run as soon as the output starts looking wrong?

Yes, provided you are sure it is a content problem and not a stalled scene, because those have opposite answers. Once you have decided the output is wrong, every scene the run still has to render is spending credits on a video you have already rejected, and stopping leaves the finished scenes untouched. On a long recipe the difference between calling it at scene four and calling it at scene fourteen is most of the run.