Luma: Requests, Credits and Files After Create

You press Create, wait, and press it again because nothing seems to happen. Did you start two videos? Will both cost credits? And if the provider finishes while the app still shows a spinner, where is your file? Those questions belong in the product brief before a developer or coding agent builds the button.

I’m Daniel Goldman. Luma is one of the projects in my portfolio. This case looks at the work around an AI generation request: identifying a repeat submission, connecting credits to a creation and keeping a usable output. It concerns Luma at luma.ai, which identifies itself as separate from Luma Labs and Dream Machine.

What was checked, and what was not

For this article, the public home, photo and video pages were checked on October 2, 2026, alongside a committed implementation snapshot. The local page checks returned the public creation interface. A separate web fetch reached a region-unavailable notice, so availability can differ by location. A public page describes the interface; it does not prove that a paid request completed.

The implementation observations below come from reading code. No paid generation, credit-ledger refund or end-to-end media transfer was exercised for this case. They describe paths that exist in the inspected implementation, not a guarantee about every request in production. The practical checks later in the article are proposed acceptance tests, not reported customer results.

Luma: public product and identity

Luma: photo creation interface

Luma: video creation interface

A repeated request needs the same identity

In the inspected generation service, a request carrying the same client request ID for the same user can return an existing generation. That gives the product a way to recognize a resubmission. The condition matters: two requests with different IDs are not made equivalent just because their descriptions happen to match.

For a founder, the useful decision is when to preserve that ID and when to start a new request. A retry after a lost response and a deliberate request for another variation have different meanings. Write down both. A disabled button may help the interface, but it does not answer what the server should do when the same request arrives again.

Credits should be traceable to a creation

For a generation that consumes credits, the source links the debit to that generation. It also contains a refund path when the provider call fails. That relationship gives an investigator something concrete to follow: which creation a debit belongs to, what failed and whether the recovery path ran. Seeing the call in code does not establish that a refund reached a particular account.

Avoid an acceptance criterion as loose as “refund on error.” Specify the error being tested and the evidence required. A provider rejecting the initial request is a different case from an output failing to copy after generation. Do not assume that both failures should have the same financial result. That policy needs a product decision and a separate test.

Provider completion is not the last step

The inspected media flow includes copying the generated output into product storage and recording a stored state. A provider returning an output and the application having its own usable copy are distinct events. That distinction helps explain why a creation can need further handling even after generation itself has finished.

A useful check follows the file all the way to the user’s action: open or download the saved output. It should also cover a failed copy and the status shown while that failure is unresolved. The existence of storage code is not evidence of permanent retention, successful delivery for every request or a particular recovery time.

A small brief for a developer or coding agent

Keep the first task narrow. Ask the developer or agent to map the existing lifecycle before changing it, then choose one failure case to reproduce in a controlled test environment. Use synthetic inputs and mocked provider responses first; a real paid-provider test needs its own authorization. These are proposed checks for a product brief:

1. 01Resubmit a request for the same test user with the same request ID. Inspect the generation records and provider-call count. Record what actually happened instead of assuming the button prevented duplication.
2. 02Simulate a rejected provider call after a debit. Check the creation status and the relevant credit entries. The success condition is the intended ledger change, not merely reaching a refund function.
3. 03Simulate an output-copy failure. Inspect the stored state and the user-facing status; then test the intended recovery. Keep provider completion and file availability as separate assertions.
4. 04For each check, retain the request ID, command, observed result and remaining uncertainty. Stop if the required behavior is undefined. Do not invent a refund policy or claim success from a screenshot alone.

Bring the failure case into the first version

A working generation demo answers whether a model can produce something. A product brief also has to explain the wait, the retry, the credit entry and the saved file. In this Luma case, the inspected code makes those decisions visible without proving every runtime outcome. That is a useful starting point for discussing what a first version must handle and what still needs verification.

Work with Daniel Goldman on AI product development