Skip to content

Cache and Re-generation

The pipeline caches outputs aggressively to save money. That's mostly a good thing — but sometimes the cache works against you. This page covers what gets cached, when it's wiped automatically, and how to force a fresh roll when needed.

What gets cached

Two layers of caching:

Generation Runner cache
When a node runs successfully, the Generation Runner stores the output (R2 URLs, picked candidates) inside the source .nbflow. Next run, nodes that already have valid output are skipped — the runner reuses the cached result instead of regenerating.
R2 storage
Every uploaded reference image and every generated output lives in Cloudflare R2 with a public URL. Once it's there, it stays — never expires automatically.

When the cache works for you

The cache is the right call when:

  • You ran 8 scenes; 2 failed; you fix the 2 and rerun. Only the 2 failed scenes need to regenerate — the other 6 reuse cached output. Saves 75% of the cost.
  • You're iterating on Scene 3's prompt; everything else is fine. Only Scene 3 needs to regenerate.
  • You change which candidate is approved in PatchWork; you don't need to regenerate, just re-pick.

When the cache works against you

  • The output exists in cache, but the prompt changed since then — and you want fresh output reflecting the new prompt
  • You want a fresh re-roll with different seeds even though the prompt didn't change
  • The cache reference points to an R2 URL that's gone stale (rare but possible after a brand sweep)
  • The cached output was actually bad and you accepted it; you want to redo it

In all these cases you need to bypass or wipe the cache.

How the Generation Runner handles cache automatically

The Generation Runner runs a cache-wipe pass automatically at the start of every run:

  • Wipes stale generation output from the workflow file
  • Preserves prompts, reference images, schema, and user picks
  • Then runs only the nodes that need fresh output (because they have no cached output OR you explicitly flagged them)

So in most cases, you don't have to think about cache management. Just run the workflow and the right things regenerate.

Forcing a fresh roll on a specific node

When you want a fresh re-roll on a specific scene — same prompt, new seed — invoke per-node rerun:

You: rerun Scene 03's image gen with a fresh seed. Don't reuse the
     cached output.

Claude: [calls regen-nodes.py on Scene 03's NanobananaAPI node, ignoring
         cache, producing 4 new candidates]

regen-nodes.py always ignores cache for the targeted nodes. See Rerunning Failed Nodes.

Forcing a full wipe

If you want to regenerate everything in a workflow (rare — usually expensive), you can wipe the entire cache:

You: wipe the cache on XYZG3-V1 and regenerate from scratch. I want
     completely fresh output across all scenes.

Claude: [wipes all cached outputs from the .nbflow, then invokes the
         Generation Runner — every node regenerates]

When you'd want this:

  • A major model update happened and you want fresh output reflecting it
  • The reference image was swapped and you want every scene to use the new one
  • You're explicitly running a fresh comparison

When NOT to do this:

  • You're just iterating on one scene (use per-node rerun)
  • You're worried about old outputs being "stale" — they're not unless the prompt changed
  • You want to test what changes (use one scene's per-node rerun for cheaper signal)

How prompt changes interact with cache

This is subtle and worth knowing:

  • The Generation Runner detects when a prompt has changed since the last run
  • If the prompt changed, the corresponding output is treated as stale and regenerates
  • If the prompt is unchanged, cached output is reused

This means: editing a prompt is the simplest way to force a regen of just that node. The cache-wipe behavior is automatic.

You: edit Scene 05's image prompt to add "wearing reading glasses",
     then rerun the workflow.

Claude: [edits the prompt, saves the .nbflow, runs the Generation Runner.
         Only Scene 05 regenerates — its prompt changed. Other scenes
         reuse cached output. Bumps V0-N counter.]

R2 storage lifecycle

R2 doesn't auto-expire. Every generated output and every reference image you've ever uploaded stays unless someone deletes it.

In practice you don't manage this — there's plenty of storage quota. But if you ever need to know which version of a workflow produced which R2 URL, the -generated.nbflow is the audit trail. The filename includes the timestamp.

If you delete the source .nbflow but keep the -generated.nbflow, the R2 URLs in it still resolve. You can re-open it in PatchWork and the candidates still load.

Cache wipe in a recovery scenario

The most useful cache-wipe scenario: recovering from a corrupted workflow file without losing the R2 outputs.

  1. Workflow was running fine; an edit broke its schema
  2. You restore the workflow file from backups/
  3. The restored file may have stale generation cache pointing to outputs you've already discarded
  4. Wipe the cache, rerun — the runner produces fresh output, you pick again

Detailed in Chapter 13 — Troubleshooting.

When you're ready

You've reached the end of Chapter 4. You now know:

  • How to spot AI tells when reviewing
  • The rules every image and video prompt must follow
  • How to validate a workflow before generating (sanity check)
  • How to dial in a stubborn prompt with the prompt-tuning skill
  • How cache works and when to force a fresh roll

That's the full quality / testing toolkit.

→ Next: Chapter 5 — Lvl 3-4 Variants. Bigger variants — environment / camera / setting changes (Lvl 3) and structural changes (Lvl 4). These go through a testing phase before approval.