🧮 Luma Ray API Pricing: What a Real Video Batch Actually Costs

I read the API reference before the pricing page, and with Luma that habit paid off, because the pricing page and the reference don't fully agree with each other once you go past the top-line "$X per second" headline. If you're scoping a real batch job, not a single demo clip, the model version, the resolution, and the dynamic range each move the number independently, and the marketing copy only ever shows you the best case.

By the numbers#

• Ray3.2, 1080p standard dynamic range: roughly $0.24/sec, so a 5-second clip lands around $1.20
• HDR output: roughly 2x the SDR rate. HDR-plus-EXR: roughly 3x
• Ray3.14 (the newest release as of this writing): Luma claims ~3x cheaper per second than base Ray3 at 720p, with 4x faster generation. A vendor claim, not independently reproduced here
• Build tier usage cap: $5,000/month. Scale tier: capacity sold in units, 1 unit ≈ 1 request/min (Base) or 0.4 requests/min (Max), 4-unit minimum

The batch math the landing page skips#

Say you need 100 clips at 5 seconds each, 1080p SDR, for a production run. At roughly $0.24/sec, that's $1.20 per clip, or $120 for the batch, a number you can actually put in a client quote. Bump that same batch to HDR because someone asked for a "premium" delivery and you're at roughly $240. Ask for HDR-plus-EXR compositing layers and you're near $360, for the identical 100 clips, same 5 seconds each. The resolution and dynamic range toggle is the single biggest lever on your bill, bigger than which Ray version you picked, and it's the toggle most cost breakdowns don't even mention because they price a single SDR clip and call it done.

Compare that against what we found pricing out a render-and-retake budget across the broader AI video market: the pattern holds everywhere. The sticker price is real, but it's the multiplier you didn't budget for that determines your actual invoice.

Ray3, Ray3.2, Ray3.14: pick one and verify it yourself#

Luma ships model updates fast enough that a pricing figure quoted in a March article can be describing a model two releases behind what's live when you read it in August. Ray3.14 is the newest as of this writing, and Luma's launch material claims it eliminates the old quality-speed-cost tradeoff: 3x cheaper, 4x faster, at 720p specifically, compared to base Ray3. That's worth taking seriously as a direction, but a vendor benchmark measured on the vendor's own hardware and prompt set is not the same thing as what you'll see on your workload. Before you commit a production budget, run the smallest test batch that would actually tell you something: five clips, your real prompts, your real target resolution. Read the invoice, not the announcement.

So what: price your actual workload before you price the vendor's demo reel.

Rate limits: you're buying concurrency, not a quota#

The Build tier's $5,000/month figure is a spend ceiling, and it's easy to misread as a rate limit. It isn't one. You can burn through it in an hour of aggressive batch generation or spread it across the whole month; Luma doesn't throttle your requests-per-minute on that tier, it just stops you cold once you hit the dollar cap. If your pipeline needs guaranteed concurrent throughput, say, a queue that has to clear a few hundred clips overnight without babysitting, that's what the Scale tier's unit system is actually selling you. One unit buys roughly 1 request per minute on the Base tier, or 0.4 on the Max tier (Max presumably does more per request, which is why each unit buys less throughput), with a 4-unit floor on any Scale purchase.

Translate that into your own pipeline before you buy anything: a 4-unit Base allocation gets you roughly 4 requests/minute, which is 240/hour if every request completes instantly. It won't, because generation time eats into that ceiling in practice, and a slot isn't free again until the render finishes. Script a small burst test against your actual account limits before you architect a batch job around a number from a docs page. Docs drift; your account's real behavior under load is the only number that pays your bill.

How this stacks up against the field#

Luma isn't unusual in making you dig for the real per-second number. It's the norm across this category right now. Kling prices on a credit system that takes its own spreadsheet to translate into dollars-per-clip, and our Veo vs Kling comparison ran into the same problem: two vendors, two incompatible pricing units, and no honest way to line them up without running the same test batch through both and reading your own invoice afterward. If you're shopping across vendors instead of committing to one, budget the time to run that same small test batch through each candidate before you sign anything. The sticker prices aren't on the same scale, and the marketing pages will never tell you that.

The invoice check#

Every time I've quoted a per-second API price in an article, someone eventually emails to say their actual bill didn't match. Usually it's a model-version mismatch, sometimes it's an HDR toggle left on from a previous job, occasionally it's a currency or regional pricing difference the landing page didn't disclose. None of that is unique to Luma. It's endemic to API-priced generative video right now, where the model catalog changes faster than anyone's blog post about it. Treat every number in this piece, including mine, as a starting estimate to verify against your own dashboard before a real production budget depends on it.

So what: budget off your account's actual invoice history, not off any single article's per-second figure, this one included.