Check generation status from the command line

Do not invent a status CLI command

This is a command-line workflow decision guide, not documentation for a status subcommand. The published parser accepts `models`, `balance`/`credits`, `generate`, and help forms. It does not expose `status` or `get-generation` as a standalone CLI command. The first-party README lists the MCP `get_generation` tool, and the public client implements a generation lookup for a supplied UUID.

Reject guessed status tokens before spawning the CLI. Its unknown-command path prints help and returns failure; it does not query a job and must not be interpreted as an empty status response. If the generation workflow returns a `generationId`, preserve it and use the documented MCP tool or public client for later status reads.

Query the durable generation identifier

The public client validates the identifier as a UUID and requests `/api/v1/generations/<uuid>`. Save that identifier as soon as `generate` succeeds, because a prompt or model name is not a unique lookup key. A status read is non-generating and should be your first action after a terminal disconnect, local parse error, or wait timeout. This avoids creating duplicate work merely to rediscover what happened to the original request.

Reject guessed tokens such as `status` before spawning the CLI. The parser's default branch prints help and returns 1, so a wrapper must not parse that text as an empty or unknown job. Send the saved UUID to the documented MCP `get_generation` surface instead.

Interpret state conservatively

The public wait implementation treats `completed` and `failed` as terminal. Other values should be considered current observations, not promises about eventual completion. Check for the status field before reading output information, and retain any returned error only as data associated with that job. Do not make up a universal pending-state vocabulary from unrelated services; code automation against the current first-party response and fail visibly when the shape changes.

Validate the saved value as a UUID at the workflow boundary and keep it unchanged in logs, status reads, and subsequent download or cancellation decisions. The public client applies the same validation before constructing `/api/v1/generations/<uuid>`, preventing prompts or display names from becoming accidental lookup keys.

Keep output retrieval separate

When `waitGeneration` returns a terminal payload, the client processes an `outputUrl` if one is present and only emits an absolute URL when it belongs to the configured Studio origin. Status checking is not the same as downloading a file. Use the documented MCP `download_output` tool after completion, and do not treat an absent URL on a nonterminal response as evidence of failure. Store the UUID, rather than an output URL, as the workflow reference for later status reads.

Require `status` to be present before evaluating output fields. Treat completed and failed as the terminal values evidenced by the wait helper; for any other returned value, retain the payload and schedule another read without inventing a state transition. This keeps the coordinator aligned with current client behavior.

Build a safe recovery branch

When automation resumes, load the prior UUID, call `get_generation`, and branch on the returned state. Continue waiting for active work, collect output for completed work, surface the error for failed work, and require explicit approval before starting a replacement. Log package version and timestamps without credentials. The npm registry reported package version 0.1.2 on the research date. Recent search results were unrelated to OfflineCreator status behavior and several sources were unavailable, so no anecdotal reliability or completion-rate claim is generalized.

Recovery should load the UUID, perform one status read, and choose a next action from that response. Completed work may proceed to documented retrieval, failed work should preserve its error, and unresolved work should remain attached to the same record. Starting another generation belongs behind a separate operator decision.

Related reading