OfflineCreator CLI for creative automation engineers

Use the CLI as a narrow JSON boundary

CLI creative automation works best when the command line is a small, inspectable boundary around a paid media job, not an autonomous art director. The published @offlinecreator/mcp 0.1.2 artifact implements models, balance or credits, and generate commands. Its command handler prints successful values with JSON.stringify, including the result returned after generate or generate --wait. Capture that stdout as an opaque response first, validate it against the fields your worker actually requires, and reject malformed or unexpected data instead of scraping conversational text.

Keep the creative decision outside that boundary. A job specification should already contain the approved prompt, selected workflow, aspect ratio, maximum credit cost, output destination, and reviewer. Run model and balance checks before generation, compare the parsed response with that specification, and stop whenever the required evidence is absent. Machine-readable output makes those gates implementable; it does not itself approve the creative, authorize publication, or establish that a returned field is safe to trust without validation.

Calculate the spend ceiling before dispatch

OfflineCreator's current catalog lists model-specific generation costs: FLUX Schnell at 1 credit, Recraft V3 at 5, FLUX 1.1 Pro Ultra at 8, Kling 2.6 Pro and Kling 2.6 Pro Motion at 42 each, and Veo 3.1 Fast at 96. These are first-party published prices, not quality rankings or a guarantee that the catalog will remain unchanged. Query the live model list and balance at execution time, then compare the returned values with a versioned policy in your job manifest.

Set both a per-job ceiling and a batch ceiling. A useful preflight record includes requested model, observed model cost, starting balance, maximum attempts, and the person who approved the budget. Stop before generation when any value is missing or stale. The Studio product page says web, MCP, CLI, and API generations share the same account balance and published per-model costs, so a separate browser session can change the capacity available to an automation worker.

Separate CLI convenience from the full job lifecycle

The plain CLI currently offers one generation command with an optional --wait flag. The same published package documents a wider MCP/API lifecycle: start generation, inspect status, wait for a result, download a completed output, cancel a reserved job, and list recent jobs. Do not imply that every lifecycle action has a dedicated CLI subcommand. For an automation that must resume, cancel, or reconcile jobs independently, use the documented MCP tools or API surface rather than inventing unsupported shell flags.

The version-pinned client polls the generation endpoint until status is completed or failed. When its wait duration expires, it fetches the latest state and returns it with timedOut: true rather than converting that state to failed. Mirror that distinction in your worker: persist the generation identifier before waiting, record a local timeout as an orchestration condition, and require reconciliation before retrying a paid request whose server outcome is unknown.

Thin CLI

Inspect, budget, start, optionally waitUse documented commands only; successful command output is JSON.

MCP or API

Status, cancellation, output, reconciliationUse the separately documented lifecycle operations when a worker must resume safely.

Human boundary

Approve spend and publicationMachine-readable state does not replace review of rights, accuracy, brand fit, or release intent.

Write a generation manifest that survives retries

Before invoking the service, write a manifest with your own deduplication key, campaign or ticket reference, prompt hash, model id, ratio, expected credit cost, input checksum when applicable, approval identity, and output directory. The version-pinned CLI artifact accepts model, modelId, prompt, aspect, aspectRatio, and wait in its documented command paths; it does not expose a CLI idempotency flag. Treat your manifest key as a local control, not as proof that the service will deduplicate two submissions.

Use a state machine with explicit transitions: planned, approved, submitted, processing, completed, failed, cancellation-requested, cancelled, and manual-review. Never infer failure only because the local wait command timed out. Never infer success only because a URL-shaped field exists. Retrieve current job state, validate that the identifier belongs to the intended manifest, then copy the completed asset into a controlled destination with its response metadata. Keep captions, claims, logos, and publication steps downstream and editable.

Before spend

Manifest plus approvalRecord model, observed cost, balance, prompt hash, ratio, retry ceiling, and reviewer.

After submit

Persist the generation idResume by status lookup; do not create a replacement merely because a worker restarted.

After completion

Validate and stageStore response metadata and route the media to human review, never directly to publication.

Treat rate limits as flow control, not retry targets

OfflineCreator's public Acceptable Use Policy applies to the web Studio, personal API keys, MCP server, and CLI. Its automation section allows use through personal API keys, MCP, or CLI only within published rate limits and makes the account holder responsible for requests made with the key. The fetched public policy does not state a numeric threshold, so this page does not publish one or treat an internal implementation value as an external service contract.

Build flow control without hard-coding an unverified quota. Limit local concurrency, use one poller per generation, retain unsent work when the service rejects a request, and surface the response to an operator. Backoff timing, daily ceilings, and reset behavior should come from current public documentation or the live authenticated response observed by the integration team. A stale number is more dangerous than an explicit unknown because it can turn a bounded queue into an accidental retry storm.

Choose the next path by operational need

Use the developer use case when the unresolved question is client connection or tool scope, the creative-agency path when outputs need a client proof and approval package, and the MCP creator-use-case directory when the desired deliverable is still unclear. Return to Studio only after the automation has a written spend gate, terminal-state policy, output staging location, and named human reviewer.

Evidence boundary for CLI creative automation

Treat this draft as an integration design, not as evidence of practitioner adoption, production reliability, throughput, output quality, broad client compatibility, or customer outcomes. Its supported product facts are limited to the linked package artifact, public product pages, model catalog, and acceptable-use policy. Recent engine retrieval returned adjacent CLI and automation discussion, but no OfflineCreator CLI practitioner cluster cleared the relevance floor for adoption claims.

Before production use, test the exact package version and account scopes in an approved environment. Record the live model response, successful JSON shape, failure body, rate-limit response, wait timeout, cancellation result, credit ledger movement, and output retrieval behavior. Keep publication and additional spend behind human approval until those observations are reviewed.