Retry a CLI generation without creating duplicate work
Reconcile status and recent jobs before retrying after a timeout or transport failure.
Connect OfflineCreator with OAuthReconcile the original job before generating again
After a timeout, disconnected terminal, or lost stdout, do not immediately repeat `offlinecreator-mcp generate`. The current CLI implements `generate` as the operation that starts work, optionally waits, and prints the returned JSON. It does not expose standalone `status`, `list`, or `retry` commands. Preserve the generation UUID from the first response whenever possible, then use the read-only MCP tools for status or recent history. An unknown CLI command prints help and fails; it is not evidence that the original generation is missing.
The safe decision is based on whether the first POST may have reached the service, not on whether the local process received its response. If a transport error happened before a UUID was saved, use `list_generations` to inspect a bounded recent response without assuming undocumented record fields. When the returned data does not identify the original work unambiguously, stop for operator review instead of guessing or creating another paid job.
Separate the write from recovery reads
The public client sends generation creation to `POST /api/v1/generations`. Status and history are different requests: one generation is read at `/api/v1/generations/<uuid>`, while recent work is read from `/api/v1/generations?limit=<n>`. The creation request shown in the client has no idempotency-key header. That does not prove the proprietary backend never deduplicates, but it means a recovery script cannot claim retry safety from a client-supplied idempotency key.
Model recovery as two phases. The write phase may create work and must capture its returned UUID. Every uncertainty branch should then move into read phase: load the saved UUID, or list a small recent window when the UUID was lost. Only a deliberate replacement decision should return to the write phase. Do not use prompt text alone as identity because separate legitimate jobs can share a prompt, model, and aspect ratio.
Treat a wait timeout as unresolved work
The public wait helper polls the same UUID until it sees `completed` or `failed`. Its defaults are a 120-second observation window and a 1.5-second polling interval. When the deadline passes, it performs one final status read and returns that payload with `timedOut: true`; it does not submit another generation. A timeout therefore describes the client’s wait window, not a confirmed remote failure and not permission to replay the original create request.
Persist the final timeout payload with the UUID and last observed status. Resume later with `get_generation` or `wait_generation` against that same identifier. A shell wrapper should keep its own retry budget for read operations separate from any budget for creating replacement work. This distinction lets status polling recover from temporary network failures without silently turning each polling failure into another generation.
Use a conservative recovery decision path
Start with the strongest durable evidence. If a UUID was saved, query exactly that job. If no UUID was saved but the create call may have reached the API, request a bounded recent list and inspect only the fields actually returned. The public client defaults that list request to 20 and types its entries as unknown values; it does not publish a timestamp, model, status, retention, or archival-completeness contract for list results. Ambiguous output therefore requires operator review.
Branch on a status response for the known UUID, not on the original terminal symptom. The public wait helper recognizes `completed` and `failed` as terminal and otherwise keeps observing until its deadline. Put any replacement generation behind explicit approval and record why it was considered separate. Read-only status, wait, and list tools reconcile existing account state; the tool metadata does not classify `generate` as read-only.
Keep the billing boundary explicit
Current first-party tool metadata labels `get_generation`, `wait_generation`, and `list_generations` as read-only, while `generate` is not read-only. It describes cancellation more narrowly: cancel a reserved generation before provider submission and refund credits. Do not broaden that statement into a promise that every failed, timed-out, submitted, or duplicate generation receives a refund. The public repository excludes the proprietary credit and generation backend, so it cannot verify backend deduplication or every billing transition.
Before authorizing replacement work, retain the saved generation identifier and only the response fields needed for the decision. Do not assume that list entries expose a particular timestamp, model, or status shape, because the public client types those entries as unknown values. Never log an API key or copy an entire prompt-bearing response when a smaller reconciliation record is enough. If billing outcome remains uncertain, pause rather than infer a refund from a client timeout.
Keep unsupported outcomes out of the runbook
This guide makes no community-derived claim about duplicate frequency, typical completion time, reliability, or customer billing outcomes. Its workflow is limited to behavior visible in the cited first-party parser, client, tool definitions, and repository documentation. Treat anything beyond those sources as unknown rather than converting a transport symptom into a product promise.
Recheck the installed package and current first-party documentation before automating recovery. Keep the durable UUID when one is returned, separate read-only reconciliation from the generation write, and require approval before a replacement. The cited public repository excludes the proprietary hosted credit and generation backend, so this page does not claim backend deduplication, universal refunds, or a guaranteed history-record schema.