Hey folks! 👋 Data engineer here, used to calculating TCO for pipelines, now helping my marketing team budget for a massive Midjourney project. We need to generate around 10,000 unique branded images for a new campaign.
I've been digging into the pricing plans, and it's not as straightforward as our data pipeline costs! The subscription model is clear, but the "GPU minutes" and "relaxed vs. fast mode" variables make my per-image calculation wobble.
Here's my back-of-the-napkin math so far, assuming a Standard Plan ($30/month):
```python
# Assumptions for a Standard Plan user:
monthly_subscription = 30
fast_hours_included = 15
cost_per_fast_hour_over = 4
# My project estimates:
estimated_images_total = 10000
avg_seconds_per_image_fast = 60
avg_upscales_and_variants_per_image = 2
total_compute_seconds = estimated_images_total * (avg_seconds_per_image_fast * avg_upscales_and_variants_per_image)
total_compute_hours = total_compute_seconds / 3600
```
The big question is how to factor in the **included GPU time** and the switch to "relaxed" mode. If we go over the 15 fast hours, do most of you just flip to relaxed and queue things up? Does that mean the marginal cost per additional image in relaxed is effectively $0 until you hit a usage cap?
For a corporate project where timing matters, we might need to stay in fast mode. I'd love to hear from anyone who's run a batch this big:
* How did your actual GPU usage compare to your estimates?
* Did you lean on relaxed mode, and did it impact your project timeline?
* Any hidden costs or pitfalls in the billing (like those stealthy "Vary (Subtle)" commands eating more time)?
Just trying to ship this project without the CFO asking me why the image gen bill looks like our Snowflake spend 😅.
ship it
ship it
Great start on the breakdown. You're right that the switch to relaxed mode is the key variable.
In my experience for a batch job this size, you absolutely want to factor in a mix of modes. The 15 fast hours will burn quickly. I'd calculate a two-phase cost: use fast mode for the initial 15 hours of GPU time (which is good for about 900 images at your 60-second estimate, not counting variants), then queue the rest in relaxed. The marginal cost for those relaxed images is basically zero on the subscription, but you have to price in the time delay.
Don't forget to account for the subscription cost itself as a fixed base. Your per-image cost plummets if you can spread that $30 over all 10k images, but only if you're willing to wait for the relaxed queue.
The "price in the time delay" bit is the real kicker, isn't it? I once tried to explain to a PM that our "basically free" relaxed queue images had an estimated delivery date of "some time before the heat death of the universe." They were not amused.
Your two-phase model is smart, but you gotta factor in the human cost of context switching. Burning that fast time on 900 images means someone's babysitting the queue, then you have to remember to check on the relaxed job three business days later when you've mentally moved on to putting out the next fire. That's where the real TCO hides.
You've identified the core variable. The problem with your current calculation is it treats all compute as "fast" and then tries to subtract a bucket of included hours. That's not how the system's economics work in practice.
Your total_compute_hours variable is misleading. For a 10k image project, the vast majority of your compute will be in relaxed mode, which has no marginal GPU cost but carries a significant time cost. You need to split your model. Calculate the fast mode hours needed for any time-sensitive iterations or urgent batches, then treat the rest as a relaxed queue with zero direct compute cost. The subscription fee becomes your primary fixed cost to amortize.
The real calculation isn't cost per image, but cost per image within a required time window. If your campaign has a hard deadline, your fast hour consumption and potential overage fees will skyrocket. If timeline is flexible, your effective cost can approach $30 / 10000 = $0.003 per image, plus the labor cost of managing a week-long queue.
Right, because labor and time aren't real costs. That's the kind of spreadsheet magic that gets projects into trouble.
"cost per image within a required time window" is just a fancy way of saying your budget is hostage to their queue. What happens when a last-minute creative change requires 500 fast-mode revisions three days before launch? Your near-zero amortized cost model explodes.
You're also assuming the relaxed queue throughput is predictable. It's not. It's a shared resource they can throttle anytime. Basing a corporate budget on a best-case, no-contention scenario is naive.
Just saying.