How the Queue Works

What happens when you submit

Your file is uploaded, a job is created, and it waits for a free GPU worker. Workers poll continuously and each asks for one job at a time. Nothing is reserved ahead of time: a job is claimed the moment a worker is free and your job is the best candidate for it.

Three tiers

Every waiting job carries a tier. A worker always takes the highest tier available, and within a tier the oldest job goes first.

How premium accounts share the fleet

There is no fixed per-account allowance. Each free worker goes to whichever premium account currently has the fewest jobs running, oldest job first when that ties. Fairness comes out of that ordering rather than a cap, which means capacity is never held back in case somebody else might want it.

• Two accounts each submitting a batch converge on roughly half the fleet each.
• An account submitting a single job has the lowest count of all, so it is served ahead of a running batch, not behind it.
• One account can hold at most 8 jobs at once, so a large batch cannot take the whole fleet.

Unpaid work yields to paid work

While any premium job is waiting, every other account is held to one job in flight. This is the rule that keeps paid separations quick, and it is why the figures below differ so sharply between tiers.

Nothing waits indefinitely

A job submitted without an account moves up into the registered tier once it has waited 10 minutes. Without that, a steady stream of signed-in work could keep anonymous jobs waiting indefinitely at busy times. It does not overtake premium work.

What actually decides your wait

• Whether anything in your tier is ahead of you. At quiet times the queue is usually empty and a job starts within seconds.
• The length of the file. Processing cost is roughly a fixed startup plus a per-second component, so a four-minute track costs far less than four times a one-minute clip.
• The model. Ensembles and multi-stem models run several passes and take proportionally longer.
• Time of day. Throughput is measured continuously rather than configured, so estimates follow real conditions instead of an assumed fleet size.

Current figures

Measured over the last 24 hours across all regions. These are queue waits — time from submission to a worker picking the job up — and do not include processing itself.

Updated every couple of minutes.

Checking from code

If you are integrating, do not guess at a wait. GET /api/app/queue/summary returns the state of your own queue so you can show a real progress indicator instead of a spinner.

queued

your jobs waiting for a worker

processing

your jobs currently on a GPU

ahead

jobs ahead of your oldest queued job

estimated_wait_seconds

seconds, deliberately conservative

throughput_per_min

measured jobs claimed per minute across the fleet

estimated_wait_seconds is null when it cannot be measured — no queued job, or too little recent activity to derive a rate. Treat null as “unknown”, never as “now”.

It is cheap enough to poll at the same interval as the separation status endpoint.

Full API documentation →

What changed recently

Scheduling behaviour described on this page is current. If you had built expectations around how the queue used to behave, these are the changes worth knowing about.