Delete tidies the library. It does not undo the spend.

A library accumulates. After a month of shoots the list is long, some of it is work you were pleased with and some of it is three attempts at the same bottle, and the instinct is to tidy. There is a delete on each entry and it does what tidying needs. The trouble is that two other wants reach for the same button, and it answers neither.

It is worth separating them before you click anything. One: you want a shorter list. Two: you want the credits back, because that take was not what you asked for. Three: you want the file gone — off the service, not just out of your view. These are three different requests and only the first is what delete is.

You cannot delete a shoot that is still being made

While any video in the shoot is queued or rendering, delete is refused outright, with a message telling you to try again once it finishes. This is not a courtesy. The render runs in a worker that writes the finished file when it is done, and if the entry had been removed in the meantime the worker would write a file that nothing points at — a video in storage belonging to a shoot that no longer exists. The guard runs before anything else for that reason.

Practically: if the button will not work, the shoot is not finished. Wait for it. A failed render is a different state and can be deleted straight away, because nothing is still coming.

The credits are gone before the entry is

Deleting a shoot touches your balance not at all. The credits were spent when the render was queued, which is the moment the work was commissioned, and removing the record of it afterwards does not un-commission it. An earlier post, "regenerate is a new take, not an edit", makes the same point from the other direction: a second attempt is charged because it is a second render. Deletion is the same arithmetic read backwards.

So delete is never the answer to "this take was wrong". If a render genuinely misrepresents the product, that is a different route with a different outcome, and tidying the entry away first throws out the evidence you would need for it. Keep a bad render until you have decided whether to report it.

What survives, and why that is deliberate

The film goes. So does the still used as the poster on a share page — the one derivative that was ever served publicly, removed on purpose so that a picture of a deleted product is not left sitting in storage with nothing pointing at it.

The uploaded photo is the interesting case. It goes too, unless another shoot still points at it. A bulk run uploads each product once and reuses that one file across every cell of the grid, so the photo behind a fifty-product run is one object with many entries referring to it. Deleting one of those entries cannot take the photo, because the others are still using it — several of them possibly mid-render. The rule the code holds to is simply never to remove an object something else still references, and the photo goes when the last shoot referring to it does.

That is worth knowing before you tidy a grid. Removing forty-nine cells and keeping one keeps the upload as well. Removing all fifty takes it.

Which want do you actually have

If you want a shorter list, delete is exactly right and costs you nothing but the record. If you want the spend back, no button does that and the entry is better kept until you have decided what to do about the render. And if you want the file off the service altogether — every photo, every output, not one entry — that is an account-level request, made by email to the address on the privacy page, and it is the only one of the three that is a promise rather than a tidy-up.

A library's delete is almost always the first of those. It is a good idea to know that it is, before you use it as though it were one of the others.