On October 6, 2026, we observed inconsistent start delays for six-second videos using lightricks/ltx-2.5-fast. All times below are UTC.
1. Run never started for approximately 20 minutes
Run: run_01M48XSZ9B8DYZ8SM3VSR8WTQV
Format: 6 seconds, 720p, 16:9
Created: 15:37:36.378513Z
We cancelled it at 15:57:43.480021Z.
Repeated status polling showed these selected fields:
{
"status": "queued",
"progress": 0,
"queue_position": 0,
"error": null,
"capacity_wait": {
"status": "delayed",
"message": "Your request is taking longer than usual to start. We're still trying."
}
}
Its events reached run.dispatching at 15:37:44.054997Z, but there was no run.started event. Cancellation confirmed started: false and credits_charged: 0.
During the stall:
- The complete account run list showed this was the only active run.
- The account had 942 provider credits.
- The public status reported API, scheduler and worker pool operational.
2. Another 720p run waited almost six minutes
Run: run_01M48Z2AETRV7VKEYP4KZ6TBT3
Provider timestamps show 5 minutes 53 seconds waiting, followed by only 16.8 seconds rendering.
3. A later 480p run completed much faster
Run: run_01M48ZFS96WRAS8BZKVMAEC6AS
It waited approximately 6 seconds and rendered in 9.2 seconds. This comparison does not establish that resolution caused the delays.
Please trace these runs and clarify:
- What blocked dispatch on the first two?
- What exactly does
queue_position: 0mean? - Were model capacity, cold starts, account limits, or stalled worker assignments involved?
- Does cancelling an uncharged queued run and submitting one fresh attempt help, or simply return it to the same capacity pool?
- What queue-start latency should we expect for customer-facing API use?