What we changed after watching two hundred failed renders
Four failure shapes, how often each one happened, and the product change that came out of each.
- Written by
- The Cetus team
- Seeds a claim
- 5
- Models
- 3
On this page5
We went through two hundred consecutive failed generations, one at a time, and sorted them by what had actually gone wrong rather than by the error code. Four shapes came out, and each one turned into a change you can see in the product.
One: the request was never possible
Just over a third. A duration the model does not offer, a model name that does not exist in our catalogue, an aspect ratio the endpoint refuses. Every one of these had been accepted by the interface, queued, charged and then failed upstream — which is the worst possible order to do those four things in.
What changed: the catalogue is now closed at the edge. A duration that a model cannot render is not selectable, and a model we do not price is not offered even though the vendor has it. The check happens before submit, so an impossible request is a disabled control rather than a refund.
Two: the batch died with the item
About a fifth. One bad line in a batch of sixty took the whole run down, so fifty-nine good prompts produced nothing and the person had to work out which line was the problem by bisecting it by hand.
What changed: failures are per generation. A batch runs to completion, the failures come back as a list you can re-run on its own, and the balance check happens against the whole batch before anything is submitted — so you are told you are short before the run starts rather than halfway through it.
Three: it succeeded and it was unusable
About a quarter, and these never appeared as failures at all — the render came back, the credit was spent, and the clip was wrong. Nearly all of them were the same three things: a face that changed halfway through, hands that came apart while holding something, and a prompt whose camera instruction was ignored.
A quarter of our failures were successes. Those are the expensive ones, because nothing in the system knew anything had gone wrong.
What changed: this is where the model split came from. Contact and faces go to Veo 3.1 Lite, explicit camera work goes to Omni Flash, and the reason each recommendation exists is a pile of these clips. It is also why reference stills moved to the front of the Director pipeline instead of being an option.
Four: something genuinely broke
The remaining fifth, and the smallest surprise: upstream timeouts, a provider account that had gone bad mid-run, transient network failures.
- Refunds are automatic and appear on the ledger as their own line, with the job attached, rather than as a silent balance adjustment.
- A generation that fails on a dead provider account rotates to another one and retries instead of surfacing an error nobody can act on.
- A job that is cancelled while still queued is never charged at all.
What we would tell you to take from it
Two thirds of these were preventable at the point of writing the prompt, not at the point of rendering it. The most useful habit we found is boring: run one clip of the shape you are about to make a hundred of, look at it properly, and only then run the hundred.
We will do this exercise again at a thousand renders. If the shape of the pile has changed, that post gets written too.
