Daily limits and the in-flight cap
Two different bounds with two different jobs: how many demos a day, and how many at once. What counts, and what does not.
Two bounds, with two different jobs. Getting them mixed up is the usual confusion, so:
The daily limit
It is a rolling window, not a calendar day. Making three demos at 4pm frees the first slot at 4pm tomorrow rather than at midnight, and nothing resets in a single lump.
It is counted per person, not per workspace. A workspace is a visibility scope; a pooled allowance would let one member lock out four colleagues on a Tuesday morning.
Pro does not raise it. The daily cap is identical on a free account and on Pro, because a quota bounds cost and a plan decides what one demo may do. See Pro, and what a lapse takes.
What counts against it
- Every demo, re-render, refresh, edit, import and scripted job you create — one each, at the moment it is created.
- Including one that you then cancel, and one that fails? No. A job that ends in failure is exempt: a crash is not a delivered demo.
What does not
- The automatic re-shoot after a capture dies on an element that has moved. You already spent an allowance on the job that failed, that job produced no video, and a failed job is already exempt — charging you for the replacement would charge twice for one video that did not work.
- Editing without rendering, previewing, sharing, renaming, filing, downloading. None of those makes a job.
Deleting is not a refund
This one surprises people and it is deliberate. Creations are counted from an append-only record rather than from the videos that currently exist, so deleting a demo does not buy back a slot.
Without that, "delete everything" would zero the day's allowance on demand: make three, purge, make three more, forever. Quotas are the product's only cost control, so a creation has to be a fact that deletion cannot un-happen. The record itself is tiny — who made it, when, and from which address — and it holds nothing about what the demo was.
The in-flight cap
A different axis entirely. It bounds how much of the queue one person may be occupying at once, because ten of one account's jobs is hours in which nobody else's first demo starts.
- It is enforced when a job is created, and nowhere else. A job that is already claimed by a worker cannot be politely declined, so refusing later would fail a demo rather than not start one.
- A queued job counts. So does an import waiting for its upload — until the upload completes, or until the wait expires and the slot comes back on its own.
- When both bounds would refuse you, the daily one is reported first, so nobody is told to wait for a slot they could not have used anyway.
Hitting the in-flight cap is not an error. The next demo waits.
The per-address backstop
There is a third bound you will almost certainly never meet: a per-IP limit of 10 guest demos a day. It exists to bound anonymous abuse and it is never applied to a signed-in account — your team's own videos must not lock out your prospective customers.
If the address cannot be identified at all, the backstop simply does not apply. A broken proxy chain degrades to "no extra guest limit", never to "no guests".
Reading your own allowance
The chip on Settings, on the composer and in the nav shows what you have used against your limit for the current window.