List recent image and video generations from the CLI
Review account history while understanding prompt persistence.
This page explains how to make a history decision from a shell workflow; it does not describe a CLI history command. The current parser has no `list-generations` or `history` subcommand. The supported first-party surface for account history is the MCP `list_generations` tool or the authenticated API client.
Fail a wrapper immediately when it receives a guessed history token. The parser's help output and nonzero status are an invocation failure, not an empty account. Use the MCP result only as a bounded account-history view. The public client types each array entry as unknown, and the server publishes no item-field schema, so inspect and validate the authenticated response before selecting any record or attempting item-level follow-up.
Understand the current client request
The public client requests `/api/v1/generations?limit=<n>` and defaults to 20 when its method is called without a limit. The MCP server accepts an optional integer limit from 1 through 100. Treat the returned `generations` array as the current account response, not an immutable archive or pagination promise. The first-party code guarantees the collection shape, but it types entries as unknown and does not publish stable UUID, status, model, prompt, or timestamp fields for list results.
Treat an unknown `history` or `list-generations` CLI token as invocation failure, not an empty account. Invoke the documented MCP tool, validate that its response contains an array, and inspect the current authenticated records before building field-dependent logic. A wrapper should fail closed when required fields are absent or have unexpected types instead of guessing a payload schema.
Handle prompt-bearing records carefully
The current first-party privacy policy identifies prompts, source images, chosen settings, and generated images or videos as generation content. It says generation history and media are retained until the user deletes them or closes the account, subject to short backup windows. That is a service-level retention disclosure; it does not enumerate which of those values appear in a `list_generations` record.
Minimize where you copy an authenticated history response. Do not send the full payload to logs or third-party analysis by default, and extract only fields that are actually present and validated for the immediate task. Pass an explicit bounded limit and record it with the response. The client defaults to 20, but public code does not document pagination or archival completeness, so absence from one bounded result is not proof that a generation never existed.
Use history for reconciliation, not duplication
Use history as an operator review surface, not as proof that a particular job is safe to reuse, cancel, or download. The README documents `get_generation` and `download_output` as separate tools, but the list payload's item fields are not publicly specified. Do not assume that every list entry contains a UUID, status, model, prompt, or timestamp, and do not submit a duplicate generation merely because one bounded result lacks an expected record.
If an authenticated response exposes a candidate identifier, validate its type and require an operator to resolve ambiguous matches before passing it to an item-level tool. A prompt string alone is not a safe idempotency key. Reduce any operational log to the minimum validated values needed for the decision, and fail closed when the current response cannot support a reliable match.