Video generation from the command line

How to render a video clip from a terminal

Three commands and no vendor account. The render is a background job, so the third step is written to be interrupted.

1. Install and log in once. Run npm i -g @clize/clize and then clize login. That is the only credential in the flow — there is no Google or Veo API key to fetch, export or rotate, because the upstream credential belongs to the platform rather than to you.
2. Price the clip before you render it. Run clize gen video "your prompt" with no --confirm flag. It returns a JSON quote of $0.48 and renders nothing. Neither --aspect nor --duration changes that number, because a clip is billed per clip rather than per second.
3. Submit it in the background, then collect it. Add --confirm --async and the command returns a job id instead of blocking. Later, in any session, clize gen jobs lists what is still running and clize gen status <id> polls one job and writes the finished MP4 to disk.

The command, and the price it prints first

After npm i -g @clize/clize and clize login, rendering is one line. Run it without --confirm and it costs nothing:

$ clize gen video "a slow drone shot over a pine forest at dawn"
{
  "quote": {
    "model": "veo",
    "modality": "video",
    "estUsd": 0.48,
    "currency": "USD"
  },
  "message": "📋 Quote about $0.48 (video). Add --confirm to generate
   (confirm: true in MCP; charged to your clize balance, refused if it is insufficient)."
}

That is the real output, copied on 4 September 2026. Adding --aspect 16:9 --duration 20 returns the same $0.48 — the subject of the next section. What you did not do first: create a vendor account, obtain a Veo or Google API key, or put a secret in your shell profile. The upstream credential belongs to the platform; yours is the clize session, and what it can spend is a prepaid balance that refuses the call when it will not cover the quote.

Music runs on the same command shape at $0.12 a track, with --instrumental if you want no vocals. Images are $0.05 and are covered in generating images from the command line, which goes deeper on reference images, masks and piping a file into a deploy.

Eight seconds, and why --duration does nothing

Most video CLIs take a length. One of the better ones in this category shows --duration 6 --resolution 720p right on its homepage and bills the result in credits, so a longer clip costs more. That is a reasonable design for a tool that fronts thirty models with thirty different rate cards.

Here the flag exists and is inert, and the help text says so rather than leaving you to discover it:

$ clize gen video --help
  --duration    duration in seconds (ignored by veo — the model picks it, ≤8s per clip)
  --ref       reference images, comma-separated (character + scene images keep shots
                     consistent; veo takes up to 3)
  --from-image   first-frame image (image-to-video)
  --async            generate in the background and return only the job id (waits by default)

Two consequences to design a script around. A clip is a unit, not a duration: pricing is per clip, so estimating a shoot means counting clips rather than seconds. And anything longer than eight seconds is several clips stitched together — an editing step this CLI does not perform, so a 40-second storyboard is five or six renders plus an editor.

That is narrower than the alternatives, and the narrowness buys one thing: the estimate is trivially correct. Twelve clips is $5.76 before you write a prompt, whatever you ask for. To price a whole shoot including the takes you throw away, the video generation cost calculator works against published per-second rate cards.

Sixteen minutes: what a render actually does to your session

This is the part the tutorials skip, and it is the part that decides whether a video CLI is usable in a script. Rendering is slow and variable. Here is the real distribution from one account's history, worked out from the created and updated timestamps that clize gen show prints for each job — thirteen veo jobs, no selection:

A blocking call with a five-minute timeout would have abandoned four of those nine clips. They were not lost, because the job lives on the server rather than in the terminal. Three commands make that recoverable:

$ clize gen video "…" --confirm --async     # returns a job id immediately
$ clize gen jobs                            # running jobs first, then recent history
$ clize gen status gen_366b0679             # poll once; if finished, write the file to disk

clize gen jobs is the reconnect point, and it is blunt about scale: on this account it answers "count": 1414, "running": 4 with a note that only 50 are listed and every running one is included. The four still in flight had been submitted from a July session — image jobs, as it happens, but on the same asynchronous machinery. clize gen status polls the provider once and materialises the file if the render finished while you were away; a wrong id gets ❌ [500] Generation job gen_nonexistent not found (clize gen jobs shows them all) rather than a hang.

For an agent that is the difference between a capability and a liability: a model that starts a render, gets interrupted and returns in a new session finds its own work with one command. Without it, every long render is a bet on the terminal staying open.

What comes back, and the one thing the agent cannot do

A finished render is a file. The command writes the MP4 to ./clize-assets/ unless --out points elsewhere, and prints metadata rather than the bytes. The full record is readable at any time:

$ clize gen show gen_366b0679
{
  "id": "gen_366b0679",
  "modality": "video",
  "model": "veo",
  "state": "succeeded",
  "prompt": "Night shift at a planetary starship yard, cinematic medium-close view: …",
  "files": [ { "url": "https://files.kunavo.com/video/2026-06/…/kw5p4033n5e5c0j6n33y.mp4" } ],
  "costUsd": 0.48,
  "providerJobId": "vid_8msbL7DixlzXY4kz",
  "createdAt": "2026-06-11T06:26:35.265Z",
  "updatedAt": "2026-06-11T06:43:07.545Z"
}

Alongside the file list, a successful run prints a line that is unusual enough to quote in full: "Written to disk — you cannot watch video / listen to music; hand the path to the user and let them judge." That instruction is aimed at the agent, and it is the honest boundary of this whole category. A language model can read a PNG back and decide whether it matches the brief. It cannot watch twelve seconds of motion and tell you the pan is wrong, the cut is early or the character's hands are broken. Anything that claims an automated quality loop on video is claiming something the tooling does not support.

So a video workflow has a different shape from an image one: the agent writes the prompt, submits the job, collects the file and stops — a person opens the MP4. Building that handoff in from the start, rather than discovering it after forty renders, is most of what separates a working pipeline from a demo.

First frame, reference images and consistency between shots

The hardest thing about a multi-shot sequence is that shot three does not look like shot one. Two flags exist for that, and both are enforced before anything is charged.

--from-image first.png makes an image the first frame, which is the reliable way to control composition: generate the frame you want with gen image — where you get 16 reference images, an inpainting mask and a $0.05 retry — and only then spend $0.48 animating it. --ref a.png,b.png passes character and scene references to veo's reference mode, and the cap is three:

$ clize gen video "…" --ref r1.png,r2.png,r3.png,r4.png
❌ [400] At most 3 reference images (limit of veo's REFERENCE_2_VIDEO reference mode; got 4).

Three is a real constraint, and worth knowing before you plan a scene: it is enough for a character plus a location, not enough for a whole cast. The refusal arrives before the charge, so an over-full reference list costs nothing. --aspect 16:9 sets the frame; like --duration, it does not change the price.

The practical sequence, then, is images first and video last. Nail the look at five cents a try, then animate the frame you kept. That is also the cheapest way to absorb the throw-away rate, which on video is the number that hurts.

What a clip costs, what a failure costs, and the other CLIs

Each clip is $0.48, quoted before it renders and charged only on --confirm; neither length nor aspect ratio moves it. There is no monthly allowance to configure and no budget command — the whole control surface is the flag on each call, which stops a runaway at zero but also means you cannot hand an agent a ceiling and walk away.

Failures are refunded in full, and the record is honest about how. Four of the thirteen jobs above failed upstream. The refund arrives as a separate credit on your balance labelled with the reason, while the job record still shows "costUsd": 0.48 — it records what was quoted, not what was finally paid, so read clize balance for the settlement. That 31% failure rate is a planning number in itself: budget for retries, and be glad they are free.

Choosing between the command-line video generators

The narrowness is the point rather than a stage of development: one model priced one way, with the operational problems — long jobs, dropped sessions, failed renders — treated as the main feature instead of an afterthought. If you need thirty models, the first row is a better answer than this page is.

$ npm i -g @clize/clize && clize login
$ clize gen video "a slow drone shot over a pine forest at dawn"
$ clize gen video "…" --from-image frame.png --aspect 16:9 --async --confirm