Generate an image with the OfflineCreator CLI

Generate an image with the command that exists

Use `npx @offlinecreator/mcp generate --model <current-image-model-id> --prompt "<description>" --aspect 1:1`. The parser requires a model and prompt; it accepts `1:1`, `16:9`, or `9:16` through `--aspect` or `--aspectRatio`. Get the model identifier from `models` immediately before the run rather than copying a marketing label. Without `--wait`, the command prints the started-generation response as JSON so you can retain its generation identifier.

The image workflow is selected by the current model ID, not by an `image` subcommand. Confirm that the catalog entry fits the requested media type and cost before submission, and stop when that evidence is absent. The version 0.1.2 client sends the request to `/api/v1/generations`; a successful start response is therefore only the beginning of the workflow, not evidence that an image completed.

Choose model and ratio from current evidence

The command parser does not decide whether a model is an image model for you. Use the current catalog response and verify the model's capabilities and cost before submission. The first-party product page displayed image choices including FLUX Schnell, FLUX 1.1 Pro Ultra, and Recraft V3 on August 8, 2026, but those display labels are not a permanent CLI compatibility guarantee. An unsupported ratio is omitted by the version 0.1.2 parser instead of being forwarded as a guessed value.

Select the model from the returned catalog entry and pass only a parser-supported ratio. The CLI maps `--aspect` or `--aspectRatio` to `1:1`, `16:9`, or `9:16`; if an operator requests another shape, stop for a new decision rather than silently claiming that the unsupported value reached the service.

Decide whether the command should wait

Add `--wait` only when a single foreground process and the client polling window fit your workflow. The version 0.1.2 parser starts the generation first, then calls the wait helper when the started response does not require an upload. That helper polls every 1.5 seconds by default, stops on `completed` or `failed`, and marks the latest response `timedOut` after a default 120 seconds.

For automation that needs independent retries, omit `--wait` and save the generation UUID from the started JSON. The version 0.1.2 README lists `get_generation` and `wait_generation` as separate tools, so recovery should query the saved job rather than submit the prompt again. A second `generate` invocation is another POST to the generations endpoint, not a status check.

Treat returned output as account-bound

A completed response can include an output URL, and the version 0.1.2 client only emits absolute URLs on the configured Studio origin. The CLI parser does not provide a standalone `download` command, while the version 0.1.2 README lists `download_output` among the MCP tools. The first-party product page describes private authenticated delivery. Save the generation identifier as the durable reference and retrieve through that authenticated product or MCP flow.

Inspect the completed payload before handing an output reference to another process. The client accepts an absolute output on the configured Studio origin; for a foreign origin it removes `outputUrl` and adds `outputUrlError`. The cited client proves origin filtering only; it does not establish URL signing or expiration behavior. Do not publish the URL or use it as the job's primary identifier.

Check completion before consuming the image

A successful submission is not the same as a completed image. The client treats only `completed` and `failed` as terminal states in its wait loop. Inspect the waited response or query the saved UUID through `get_generation`, then verify the final state and the presence of an output reference before downstream use.

Build a non-secret manifest from values observed in this run: package version, catalog model ID, prompt revision, accepted ratio, generation UUID, and final state. Link any downloaded asset back to the UUID rather than making the delivery URL the primary key. The version 0.1.2 README describes model discovery, status, waiting, and downloading as distinct MCP tools, so keeping those transitions explicit makes automation easier to audit.

Related reading