Generate a video with the OfflineCreator CLI
Start text-to-video work, account for duration and credits, and wait safely.
This title describes an outcome, not a `video` subcommand. Run `models`, choose a current text-to-video model ID, check the credit response, then call `npx -y @offlinecreator/mcp generate --model <id> --prompt "<shot description>" --aspect 16:9`. The current parser exposes only the shared `generate` command for image and video jobs. The selected model determines the media type, so a remembered label is not evidence that a model still supports this workflow.
Treat the page as a model-selection and submission guide within that shared command. The parser does not expose a duration option, standalone video action, later status command, or download command. If the current catalog does not establish the required video capability or economics, stop before submission rather than translating options from another provider's CLI.
Preflight model economics and format
The current first-party model page identifies Kling 2.6 Pro and Veo 3.1 Fast as text-to-video choices at 42 and 96 credits respectively. Those are current catalog facts, not constants to embed in automation. Run `models` before submission and select the returned ID for the intended workflow; the public product page names the models but does not expose their CLI IDs. If the authenticated catalog does not return a video model ID, stop rather than guessing one from a display name.
The parser forwards a model ID, prompt, and only `16:9`, `9:16`, or `1:1`. It has no duration flag. Treat duration as model data rather than a shared CLI option, and do not translate a duration switch from another provider's command line. Recheck the live model record and account balance before spending credits.
Use `--wait` only for a bounded foreground job
When `--wait` is present and the started response does not require an upload, the CLI invokes the client polling helper. That helper defaults to a 120-second timeout and 1.5-second polling interval, stops on `completed` or `failed`, and otherwise returns the latest state with `timedOut: true`. A timeout is not proof of failure. Preserve the generation UUID and inspect it later instead of submitting the prompt again.
Persist the UUID before entering a long foreground wait. The client polls that UUID until `completed`, `failed`, or its 120-second default deadline, so a returned `timedOut: true` should enqueue a later status read for the same job. It must not feed the prompt back into `generate` automatically.
Read terminal state before using output
The wait helper recognizes completed and failed as terminal states in the public client. A completed payload may receive an absolute output URL after origin validation; a failed payload can carry an error. Check the status first, then the output reference. The current CLI does not expose standalone status or download subcommands, so long-running automation should use the matching MCP tools or public API rather than fabricating command names from tool names.
Branch on the returned status before inspecting output. A completed response may receive an origin-checked output URL, a failed response may contain an error, and a deadline response can still represent active work. Use the MCP status and download tools for later phases because those names are not standalone commands in the current CLI parser.