The refresh flag on repeat workflow runs

The first run of a saved workflow and the second run of the same workflow are not the same job. Same workflow_id, same characters, same style block, and a different plot unless you tell it otherwise. That is not a bug in the recipe. It is the freshness policy on run_workflow, and the refresh flag is how you override it.

If you treat "run it again" as "render the same scenes again," you will spend a full credit estimate on a video you did not approve scene by scene. If you treat every re-run as a brand new brief, you will lock a format that was supposed to stay still. The operator move is to know which of those two jobs you are asking for before the run starts.

What the default actually does

run_workflow takes a workflow_id and an optional boolean, refresh. Omit the flag and the server applies a heuristic. It is small, closed, and worth memorising.

A theme anchor is either the workflow's description or its series_premise. Either one counts. A re-run is any workflow that already has a last_run_at timestamp, or a run_count greater than zero.

Call	Has a theme?	Is it a re-run?	What gets rendered
First run, flag omitted	yes or no	no	The saved scenes, verbatim
Second run, flag omitted	yes	yes	A new plot, same characters and style
Second run, flag omitted	no	yes	The saved scenes, verbatim
Any run, refresh: false	anything	anything	The saved scenes, verbatim
Any run, refresh: true	yes	anything	A new plot, even on the first run
Any run, refresh: true	no	anything	Saved scenes. There is nothing to regenerate from

The first-run rule is the one people miss. The scenes sitting on the workflow are the scenes you just directed and approved. The default will not throw them away to be "helpful." Regeneration starts on the next run, and only if a theme exists to keep the series on-identity.

No theme means there is no brief to write a new episode against. The regen pass has nowhere to stand, so it plays the saved scenes back. That is why a one-off recipe you never wrote a description for will look identical on run two, and why a series recipe with a two-sentence premise will not.

What regenerates, and what does not

The regen pass is a showrunner call, not a re-roll of the whole recipe. It writes today's episode as a new, distinct story, then a scene director polishes the image and video prompts. The things it is allowed to change, and the things it is forbidden to touch, are the whole product.

Held constant across a refreshed run:

• The asset_map. Character keys, product keys, reference images. Today's episode has to reference the same keys by name.
• style_preamble and voice_preamble. Look and delivery stay put. Plot is not allowed to invent a new costume category, a new setting type, or a new aesthetic.
• Aspect ratio.
• Scene count. A nine-scene recipe stays nine scenes.
• Per-scene duration. A 3-second hook next to an 8-second payoff stays a 3-second hook next to an 8-second payoff. The regen pass echoes those numbers back unchanged so a format's pacing does not drift.

Rewritten on a refreshed run:

• The plot. Hook, tension, ending. Recent plot_summary values from prior runs are fed back in so today's episode is not allowed to recycle yesterday's setup or punchline.
• img_prompt and video_prompt per scene.
• Voiceover per scene, inside that scene's word budget. Empty voiceover is allowed when silence is the point. Padding greetings are not.

If regeneration fails (timeout, empty model output, a theme that was deleted between runs) the run still starts. It falls back to the saved scenes and records that regeneration did not happen. You get a video either way. You do not get a half-written episode.

That split is the same one you want when you promote a winning video into a reusable workflow: lock style, assets, and beat lengths; let the episode change. Refresh is that rule, applied automatically on the second run.

When to pin, and when to let it rewrite

Pass refresh: false when the point of the run is the scenes you already have.

• A client approved scene four's line reading and you need another export of the same cut.
• You are debugging a model or a caption style and the plot must not move under you.
• You are about to read the credit estimate against a known recipe, not against a new script the model has not written yet.

Omit the flag (or pass refresh: true on a later run) when the workflow is a series format. A daily cooking-hack short, a myth-buster, a product-in-a-new-situation. Those are the recipes you save and reuse because the skeleton holds and the episode should not. The same policy sits under scheduled series: a recurring video series regenerates a fresh plot on each tick while reusing the asset map and style, which is why a cadence without a premise is a silent no-op on variety.

The long recipes make the cost of getting this wrong obvious. Lumee Glow Cat Glow-Up is not a thing you want to re-approve scene by scene every time you need another episode, and it is also not a thing you want to accidentally re-render beat for beat when the brief was "same cat, new situation." Set the theme. Then the default does the second job, and refresh: false is there for the first.

A mid-flight run is a different decision. Refresh chooses which script the next run will shoot. It does not pause, resume, or salvage the run that is already going. That is stop and resume, and mixing the two is how people cancel a good first episode because they meant to pin the second.

The REST path is not the agent path

This is the other place the heuristic hides.

The agent tool run_workflow is where refresh lives. A REST POST /api/v1/workflows/:id/run instantiates the run from the saved scenes and does not take a refresh flag. If your integration always hits that route, you will never see a regenerated plot, theme or no theme. That is the correct pin if your pipeline is "render the recipe I stored." It is the wrong pin if you expected the series behaviour you see in chat.

Scheduled ticks are a third path: they regenerate from the theme on every cadence, independent of the ad-hoc flag. Translating "every weekday at 10" into the five UTC fields is a separate job, covered in the cron guide. Do not fold freshness into the cron. Cadence decides when. The theme and the flag decide what.

So before you wire a re-run, name the path:

1. Chat or MCP run_workflow with the flag omitted: series default.
2. Same tool with refresh: false: exact replay.
3. REST POST /workflows/:id/run: exact replay, no flag to flip.
4. A schedule on the workflow: fresh plot per tick, assets and style held.

If those four are not distinct in the runbook, the team will argue about "the workflow being random" when three different callers asked for three different things.

FAQ

Does the first run ever regenerate scenes?

Only if you pass refresh: true, and only if a description or series_premise exists to regenerate from. The default first run always uses the saved scenes so the version you just approved is the version that renders. Forcing regen on run one is a test move, not a production default.

I re-ran a workflow and got the exact same video. Is refresh broken?

Usually there is no theme anchor. Without a description or series premise the regen pass has nothing to write against, so it ships the saved scenes. Set a two-sentence premise ("quirky daily cooking-hack short starring Chef Mario, vertical, warm kitchen light") and the next re-run will vary. The other possibility is that the caller used the REST run endpoint, which does not regenerate.

Will a refreshed run keep my character looking like the same person?

That is the point of holding the asset_map and style preamble constant. The new plot has to reference the existing character and product keys. It is not allowed to introduce a new costume category or a new aesthetic for the day. If identity still drifts, that is a generation-consistency problem on the scene, not a freshness-policy problem on the run.

If regeneration fails, do I lose the run?

No. Failure falls back to the saved scenes and the run still starts. You will see that regeneration did not happen on the run metadata. Check the theme, then re-run. Do not delete the workflow.