Inside the render queue: how a prompt becomes a clip

Press generate and a clip appears a minute later. Between those two moments is a pipeline that has to schedule scarce GPUs, stream progress, and never lose a job. Here is what actually happens.

The job state machine

Every generation moves through an explicit set of states. Making the lifecycle a first-class state machine means we can resume, retry, and report on any job at any moment — and you can subscribe to each transition.

• queued — accepted and waiting for capacity
• preprocessing — prompt parsing, image prep, safety checks
• running — the model is denoising frames on a GPU
• postprocessing — upscale, transcode, watermark
• completed / failed / cancelled — terminal states

Picking the right GPU

The model router is VRAM-aware: it knows how much memory each model and resolution needs, and places the job on the cheapest GPU that can run it without spilling. A 720p clip and a 4K render rarely belong on the same card.

Realtime, not polling

As frames render, the worker publishes events to Redis, which fan out to your browser over WebSockets — with SSE as a fallback. You see queue.position, then job.progress ticking up, then job.completed with a signed URL. No spinning, no refreshing.

“A render you cannot watch feels twice as slow. Realtime progress is a feature, not a nicety.”

Failure is a state, not a surprise

When something goes wrong, the job lands in failed with a structured reason and your credits are never deducted. Because the lifecycle is explicit, retries are safe and idempotent — the same input never bills you twice.