Sora 2 Pro takes 10-15 minutes for a 15s HD video — David Attisaas first-impressions thread

TL;DR

@david_attisaas reports first-hand wall-clock numbers for Sora 2 Pro: 10–15 minutes to generate a 15-second video at “hd quality”, 5–10 minutes at “standard quality”, and a 15-second maximum duration. He also notes the Pro model gives 5 parallel generations (vs 3 for free Sora 2), short prompts work well, and the HD outputs are good enough that upscaling is usually unnecessary. The wall-clock numbers are the salient data point: a frontier production text-to-video system at minutes-per-clip in late 2025 implies the deployed Pro model is either large, lightly distilled, or both — a counterpoint to the open-source distillation trajectory that is pushing community models to single-digit seconds for 5-second clips.

Key claims

Sora 2 Pro generates a 15-second “hd quality” video in 10–15 minutes wall clock [tweet].
Sora 2 Pro generates a 15-second “standard quality” video in 5–10 minutes wall clock [tweet].
Maximum supported clip duration is 15 seconds (an increase of ~5 s over the free Sora 2) [tweet].
Pro users can run 5 generations in parallel vs 3 for free Sora 2 users [tweet].
Pro HD outputs are reported as visibly higher quality than free Sora 2 outputs, to the point that upscaling is often unnecessary [tweet].
Short prompts are reported to work well with Sora 2 Pro in initial tests [tweet].

Method

Anecdotal first-impressions tweet. No controlled benchmark, no prompt list, no GPU spec — these are user-facing wall-clock latencies from the hosted Sora 2 Pro product as experienced by one account. The 10–15 minute figure is reported as the observed range across an unspecified number of generations.

Results

The wall-clock figure itself is the result. To anchor the magnitude: at 24 fps a 15 s HD clip is ~360 frames, and 12 minutes of generation time is ~2 s per frame — orders of magnitude slower than community real-time / few-step video systems on a single GPU. Sora 2 Pro’s per-clip cost is consistent with a model that runs many denoising / transformer-block passes per frame, or one that is simply parameter-large enough to be slow even on OpenAI-scale serving infrastructure.

Why it’s interesting

Read against the wiki’s distillation cluster, this is the “undistilled flagship” data point. The Luma-relevant question is which axis Sora 2 Pro is spending compute on:

If it’s NFE-heavy: the production frontier is not yet living on the 1–4 NFE distillation curve that has dominated the wiki this quarter — Streaming Autoregressive Video Generation via Diagonal Distillation (Wan2.1-T2V-1.3B at 31 FPS, 0.37 s first-frame latency via DiagDistill), Cross-Resolution Distribution Matching for Diffusion Distillation (Wan2.1-T2V-14B at 25.6× speedup via RMD), and FastWan: Generating a 5-Second Video in 5 Seconds via Sparse Distillation (FastWan: 5 s of video in 5 s on a single GPU via sparse distillation) all sit far below the Sora-2-Pro wall-clock budget. OpenAI is either (a) shipping an undistilled product and absorbing the cost, or (b) running quality validation / safety passes that dominate the visible latency.
If it’s parameter-heavy: the trajectory matches frontier closed video models scaling parameter count despite community distillation gains — paralleling Seedance 2.0: Advancing Video Generation for World Complexity and Veo 3 Tech Report which prioritize quality / world-complexity over decode speed.

Either way, the 10–15 minute figure is the most concrete public latency anchor for a frontier closed video model available, and it tells the team something about the gap between “live-stream diffusion” research like MirageLSD: The First Live-Stream Diffusion AI Video Model and what OpenAI is actually willing to ship as Pro. Treat the numbers as approximate (single user, no controlled measurement) but directionally credible.