← All documentation

Deleting a video, a library or an account

Three destructive controls with three different blast radii, what each one really removes, and the one record that deliberately survives.

Three controls, three blast radii. Each one is honest about what it could not do, which is the part worth reading.

ControlWhereRemoves
DeleteA job page, a library cardOne video and its artifacts
Delete everythingSettings → Danger zoneEvery video you authored and your whole media library
Delete my accountSettings, the last bandThe above, your solo workspaces, and the account itself

Deleting one video

Objects first, then the row. That order is deliberate: a row with no objects is a broken card, while objects with no row are storage cost — and only one of those is visible to you.

  • A running job is never force-deleted out from under its worker. Cancel it first; the control on the job page does that in one press, and a cancelled job is a failed job to your allowance (that is, exempt).
  • Deleting a video deletes its audience marks with it, in the same statement.
  • It does not delete the versions derived from it. A child of a deleted video simply becomes the start of the chain you can see, with no tombstone — see Version history.
  • If storage refuses, the row is kept with the objects so nothing is orphaned, and you are told rather than shown a success that did not happen.

Any workspace member may delete any video in the workspace. That is the same authority the model already grants over a colleague's work, and the workspace is what a video belongs to.

Delete everything

Behind a typed phrase — you type delete everything — rather than a checkbox. Every other destructive control acts on one thing you are looking at; this one acts on a plural you cannot see, so the guard makes you state the blast radius.

It adds no new delete semantics. It calls the per-item deletes in a loop, so the object sweep and the permission checks are the same code the single buttons run.

One press is bounded to 20 videos and 20 assets, and the remainder is reported with a "Run it again" button beside the number. A single delete costs about a dozen round trips, so an unbounded purge of a large library would outlive the request and show you nothing while having deleted plenty.

The report is honest about three separate things:

  • Skipped — running jobs, which are never force-deleted. The copy points at the Cancel control.
  • Refused — storage kept the objects, so the rows were kept with them.
  • Not counted either way — items that were not yours to delete any more. That could be a lost race or a workspace you have left, and the delete cannot tell which, so it does not guess.

Your account survives this control. Deleting it is the next section down, and the page says so.

Delete my account

Behind its own typed phrase, and a different one: you type delete my account.

It blocks before it deletes anything, and each blocker has a real remedy:

  • You own a shared workspace with other members in it. Hand it to another member from its Team page — you stay in the workspace, they become the owner — or remove them, or delete the workspace.
  • You have a job running. Cancel it. A running job is a blocker here rather than a skip, because a deleted account cannot come back later to collect a finished video.

Then the order, which is the design: enumerate everything once → delete it through the same per-item deletes, batch-bounded like the purge → at zero remaining, re-check for anything created in the meantime → clear your byline from videos in workspaces you had left → delete the workspaces you solely own → delete the account, its sign-in methods and every session.

A video in a workspace you left keeps existing and loses your name from it. Nothing that belongs to somebody else's team disappears because you left.

Two refusals worth knowing in advance

  • Your session has to be recent. A password-less deletion runs a freshness check; a day-old cookie will be asked to sign in again. It is taken before anything is destroyed, so "sign out, sign back in" can never land halfway through.
  • A guest is refused. No password means the freshness check is the only one that can run, a guest's cookie ages past it, and a guest cannot re-authenticate — "sign in again" would be a dead end. The refusal points at Delete everything, which removes everything a guest holds, and at signing up.

The one record that survives

Creations are counted from an append-only record, and deletion is not a refund.

That record outlives the video and outlives the account. It holds who made it, when, and the address it came from — and nothing about what the demo was: no URL, no prompt, no title, no artifact.

Without it, "delete everything" would zero your daily allowance on demand, and it would do so repeatedly. Quotas are the product's only cost control, so a creation has to be a fact that deletion cannot un-happen. Entries roll out of the window they matter in on their own.