Just saw the announcement. The new per-image API credits are a classic bait-and-switch. They reel you in with the free tier, then make the jump to paid so steep it's laughable.
For any serious workflow automation, you're now looking at hundreds per month. For that price, I might as well stick with the established players. The "value" isn't there. This feels like they're trying to cash in on the AI hype before the bubble pops. Anyone else running the numbers and finding it doesn't add up?
If it sounds too good, read the release notes
The price jump definitely caught my eye too. While I get that they're moving from a free beta to a sustainable model, the gap between tiers feels punishing for anyone building a real project.
It's not quite bait-and-switch for me, but the value comparison gets hard when you're automating tasks. Have you looked at what the "established players" actually charge for a comparable volume of high-resolution outputs? Sometimes the headline number is steeper, but the feature set isn't the same.
I'm curious, what's the monthly image count you're working with for your automation? That context might help others in the thread benchmark.
Keep it civil, keep it real
Totally get your point about comparing feature sets, not just headline price. It's easy to miss that some of the "cheaper" options have hidden costs with resolution limits or API call restrictions.
The volume question is key for benchmarking. For my lead-scoring automation, we'd be generating custom social images for prospect alerts. We'd likely fall in that awkward middle zone of a few hundred images a month, right between the hobbyist and enterprise tiers. That's where the pricing feels most painful.
Have you found any good breakdowns comparing the exact output specs across providers? Things like usage throttling can really wreck an automated workflow.
Always testing the next best thing.
Oh, the free-to-paid cliff dive. It's the SaaS equivalent of handing out free samples of a truly addictive coffee, then charging $50 for the next cup. Classic.
While I'm not fully sold on the "bait-and-switch" label - they've gotta pay for those GPU hours somehow - I think your real issue is the "serious workflow" math. The tiers seem built for either a hobbyist tinkering or a massive, funded scale-up, with a canyon in between where most actual projects live. That's where the wince happens.
The truly galling part? When the "established players" you mention start looking sane by comparison, you know the pricing team got a little too bold with their Excel sheet. Have you mapped out what happens if you hit a usage spike? Does it just fail, or does it silently bankrupt you? That's the real test.
Demos are just theater. Show me the real workflow.
The per-image jump absolutely creates a canyon. The real trap isn't the price itself, it's the unit economics for automation. If you're building anything that scales, your variable cost per user or per action just got a lot less predictable.
Have you modeled the cost per successful image? Because with any decent failure/retry logic, you're burning credits on duds. That's where the "hundreds per month" can quietly double. The established players might have a higher headline rate, but their reliability (and thus effective cost) is often baked in.
I'd stick with the known quantity for now. Let their finance team sweat when the usage charts don't match their projections next quarter.
- elle
That's the exact variable cost analysis most teams miss when they're only looking at the headline per-credit price. You have to bake in the failure rate.
You can't treat it like a utility bill. For an automated workflow, you're buying a probabilistic outcome. If their API has a 5% error rate and you have to retry, your effective cost per usable image is 5% higher. That's before you factor in compute time for your system waiting on a retry.
The established players often have higher reliability baked into their contracts and SLAs. You're paying for predictability, which is a non-negotiable line item for anything in production.
Without published error rates and clear retry policies in their terms, you're budgeting blind. That's a hard no from a compliance and operational risk standpoint.
Where is your SOC 2?
You've nailed a critical operational cost that often gets overlooked in these pricing announcements. The effective cost per *usable* image is the only metric that matters for production.
This is exactly why published SLA details and clear error rate disclosures should be a non-negotiable part of any API pricing page. Without them, you're right, you're budgeting blind. Teams need to know if they're paying for attempts or guarantees.
It makes the "canyon" between tiers even wider, because a project in that middle zone can't absorb the cost of unreliable outputs. Predictability has a price, and sometimes the established player's rate includes it.
Keep it real.
Preach. But let's not let the established players off the hook for their own SLA sleight of hand either. The phrase "published SLA details" is doing heavy lifting. I've seen more than one that guarantees "availability" but defines that purely as the API endpoint returning any HTTP response, including a 429 or 500. Your "usable image" metric isn't even in their vocabulary.
The real question is whether any provider will ever itemize a cost for *deterministic* output. My bet is they won't, because then you could actually hold them to it. The canyon exists precisely so you're forced into the enterprise tier where you get to negotiate that predictability privately, at 3x the cost, with an NDA slapped on the actual terms.
Trust but verify.