Every few weeks a new image generation API shows up promising “state of the art quality for pennies per image,” and every few weeks developers find out the invoice doesn’t match the demo. That’s not usually malice. It’s just that image APIs get priced, throttled, and measured in ways almost nobody explains on the landing page.
This is the version of the comparison nobody publishes: what you’re really paying for, where the limits actually bite, and why two services quoting the same per-image price can cost 8x different amounts by the end of the month.
The Three Pricing Models You’ll Actually Run Into
Almost every image API collapses into one of three billing shapes. They are not interchangeable, and mixing them up is how budgets die.
- Per-output pricing — you pay per generated image, sometimes scaled by resolution tier. Simple to reason about, brutal at scale, and the price per image usually assumes the cheapest resolution and the smallest step count.
- Per-compute pricing — you pay for GPU-seconds or “generation units” consumed. Cheaper at high volume if you optimize, but you eat the cost of retries, warm-up runs, and anything that times out halfway through.
- Subscription or credit pools — a monthly fee or prepaid credit bucket. Great predictability, terrible flexibility, and the credits almost always expire or get throttled harder than pay-as-you-go.
The trap: providers love advertising the model that looks cheapest for a hobbyist, while the model that’s cheapest for a real workload is buried two clicks deep in a calculator tool.
What “Price Per Image” Actually Covers
A quoted per-image rate is a headline number. The real cost per usable image is a different figure entirely, and it includes:
- Resolution multipliers. Doubling width and height is roughly a 4x pixel increase. Some providers price it that way, some smoothe it, some charge a flat jump that’s way worse.
- Step or quality settings. A “high quality” mode can quietly cost 3-5x the fast mode, and the API docs might describe it as a simple boolean.
- Failed and filtered generations. Plenty of services still bill you for a generation that got blocked, errored, or returned a blank frame. Check this one specifically — it’s where panic-spamming retries gets expensive.
- Upscaling and post-processing. Often a separate endpoint with separate pricing, billed per call, not per image.
- Moderation calls. Some pipelines run a safety check as a separate billed request before the image even gets generated.
- Storage and egress. The output has to live somewhere. If the API hands you a URL and you’re pulling gigabytes of PNGs through a CDN, that’s a real line item.
Do the math on cost per successful image, not cost per request. If your prompts get rejected 15% of the time and you retry twice on failure, your effective price is nowhere near the sticker.
Rate Limits: The Part That Actually Breaks Your App
Pricing hurts the wallet. Rate limits hurt the product. And they almost never look the same across providers.
The dimensions you need to pin down before you commit:
- Requests per minute — the obvious one, and the one most likely to be advertised.
- Concurrency caps — how many generations can run simultaneously. This is the real ceiling. You can have 600 RPM allowed and still be capped at 4 in-flight jobs.
- Queue behavior — does an over-limit request get a clean 429, or does it sit in a queue and time out after 60 seconds while still costing you?
- Daily or monthly quotas — a soft cap that silently resets or locks you out for 24 hours.
- Burst allowances — short windows where you can spike. Great for demos, useless for sustained scaling.
- Per-key vs per-account limits — one account with ten keys usually shares one bucket. Splitting keys doesn’t multiply your throughput the way people assume.
If the docs don’t list concurrency, assume it’s low. If they say “contact us for limits,” assume the answer is tied to a contract and a sales call.
Speed: Latency and Throughput Are Different Numbers
“Fast” means two completely different things depending on what you’re building, and providers mix them freely.
- Time to first byte — how long until anything comes back. Matters for interactive tools and streaming previews.
- Total generation time — how long the full image takes. Matters for batch jobs and user-facing waits.
- Throughput under load — how many images per minute you get when 20 requests are queued. This is the number that decides whether your product works at 3 AM on a launch day.
The biggest single factor is usually cold starts. A model that’s already warm can return an image in a couple of seconds. The same model on a cold instance can take 30+ seconds for the first request. Services that keep a warm pool charge for it — sometimes explicitly as an hourly fee, sometimes baked into per-image pricing.
Other things that move the needle: step count, resolution, model size, batch efficiency (generating 4 images at once is rarely 4x the cost of one), network region, and whether the provider is quietly sharing your capacity with everyone else on the same tier.
How to Benchmark This Without Burning Money
Marketing pages will not give you comparable numbers. You have to generate them yourself, and it’s cheaper than you think.
- Build a fixed prompt set — 20-30 prompts, same resolution, same quality setting, same seed behavior.
- Run each prompt 5-10 times per provider to catch variance.
- Record p50 and p95 latency, not just average. Averages hide the tail, and the tail is what users complain about.
- Track failures separately from successes, and note whether failures were billed.
- Calculate cost per successful image and images per dollar at realistic volume.
Ten dollars of test credits across three providers will tell you more than a week of reading docs.
Workarounds That Quietly Work
Nobody documents these because they’re not in anyone’s revenue interest:
- Fallback routing. Wire two or three providers behind one internal interface. Primary goes down or throttles, traffic shifts. Costs nothing to build and saves entire launches.
- Prompt hashing and caching. If the same prompt and settings come through twice, serve the cached result. Most apps have far more repeat requests than they realize.
- Async queues. Never generate inside a web request. Push to a job queue, poll, and deliver. It turns a rate-limit problem into a delay problem, which users tolerate way better.
- Self-hosting open-weight models. Past a certain volume, renting raw GPU time and running your own weights beats per-image pricing hard — the crossover point is lower than people assume, and you stop caring about someone else’s concurrency cap.
- Pre-generation batches. For anything predictable, generate ahead of time during off-peak windows and store the results.
- Stacking free tiers and trial credits across providers is extremely common and, in many cases, explicitly permitted within the terms. Read those terms — not all of them are fine with it, and the ones that aren’t will notice.
Red Flags on the Pricing Page
- Per-image pricing that doesn’t specify a resolution.
- No published concurrency limit anywhere.
- Overage rates that are 10x the base rate.
- Credits that expire monthly with no rollover.
- “Failed generations are non-refundable” buried in a footnote.
- Pricing that changes based on a tier you can’t see without signing up.
Picking Based on What You’re Actually Doing
Tinkering and prototyping: go where the free tier is fattest. Limits don’t matter yet.
Consumer-facing app with real users: prioritize concurrency and tail latency over headline price. A provider that’s 30% more expensive but never throttles you is cheaper than one that saves you money and loses you users.
Batch pipelines and internal tooling: optimize cost per successful image and ignore latency. This is where per-compute pricing and self-hosting win.
High-volume production: get a contract, negotiate the concurrency cap, and keep a second provider warm as insurance.
The Bottom Line
Image generation APIs are priced like a vending machine and operated like a nightclub with a capacity limit. The sticker price is real, but it’s only one of five numbers that decide what you actually pay: price per image, cost per successful image, concurrency ceiling, tail latency, and how gracefully the thing behaves when it’s overloaded.
Benchmark it yourself, price it per successful output, build the fallback route before you need it, and never trust a rate limit that isn’t written down. That’s the whole trick — and it’s the part nobody puts on a landing page.