Queue everything, then judge it together

Why one at a time is expensive

Watching a single generation render creates a specific behaviour. It finishes, it is nearly right, you adjust one word, you press generate, you watch again. An afternoon disappears and the spend is invisible because it arrived in small pieces.

Batching breaks the loop mechanically. Queue eight shots, walk away, come back to eight results, and judge them together.

The decisions are also better. Comparing eight results side by side tells you which are good; watching one at a time tells you only whether each is better than the one before it, which is a much weaker judgement.

Batching without an API

Most hosted tools let you queue several generations. Use it even when the interface makes it awkward:

• Write all your prompts and stills first, as a batch of work, before opening the tool.
• Submit them all.
• Close the tab.
• Come back later and download everything.

That last step matters more than it sounds. Staying on the page is what re-creates the loop.

When an API is worth it

If you are producing regularly, driving generation from a script is a different way of working and it is not difficult.

fal.ai and Replicate both expose most current models behind a single API with pay-as-you-go billing, which means one account rather than six. The platforms’ own APIs exist too, with their own SDKs.

A minimal loop over a shot list:

import json, pathlib, fal_client   # or replicate

shots = json.load(open("shots.json"))   # [{id, image, prompt, seconds}, ...]
out = pathlib.Path("takes"); out.mkdir(exist_ok=True)

for s in shots:
    for take in range(3):
        r = fal_client.run("MODEL-SLUG", arguments={
            "image_url": s["image"],
            "prompt": s["prompt"],
            "duration": s["seconds"],
            "seed": 1000 + take,
        })
        (out / f'{s["id"]}_t{take}.json').write_text(json.dumps(r))
        print(s["id"], take, r.get("video", {}).get("url"))

What this buys, beyond speed:

• Every parameter is recorded, because it is in the script. Your provenance problem is solved as a side effect.
• Seeds are explicit and varied deliberately, so three takes are three known draws rather than three unknown ones.
• Repeatable runs. Re-running the script with one changed field is an experiment, not a session.
• Spend is countable. Shots times takes times price, known before you run it.

Rate limits, failures and refunds

Things that will happen and should not surprise you:

• Rate limits. Providers cap concurrent jobs. Handle it with a small delay and a retry rather than by hammering.
• Failed generations. A job returns an error or a black clip. Most providers do not charge for a hard failure, and some charge for a completed-but-bad one. Check your usage page against your expected spend after the first batch.
• Content filter refusals. Hosted models occasionally decline legitimate work with no explanation. Budget for it and keep an open-weights fallback for anything the filters are awkward about.
• Silent model updates. Pin a version string in the call if the provider supports it.

Always write the response to disk, including the failures. A log of what failed and why is what tells you whether a shot is unlucky or impossible.

Local batching

If you run models yourself, batching is the default rather than a feature. ComfyUI queues as many jobs as you give it and works through them, and the marginal cost of a fourth take is electricity.

That changes the economics of experimentation completely, and it is the strongest practical argument for a local setup even if your final renders happen on a hosted model.

The habit that survives any tool

Prepare work in batches, submit, leave, review together, decide. It applies to a scripted API run, a hosted queue, or a free tier where you submit three jobs a day and collect them tomorrow.

The tool changes; the loop that wastes money does not.

Today: prepare eight shots fully before opening your tool, submit all eight, close the tab, and review them together an hour later.