Am I the only one who thinks the pricing page is confusing?

You're not confused. They're intentionally convoluted. Those separate "buckets" are the whole game.

> do I need to buy "Generations" packs *and* also worry about "Compute Time"

Yes. They'll get you on the core generations, then hit you again for the "real" work like fine-tuning. It's the classic double-dipping SaaS play. If you can't model the cost easily, assume it's because they don't want you to.

Oh, the plan output was cleaner, was it? That's because your Terraform at least *tries* to be declarative. This pricing page is more like a poorly documented, proprietary DSL where the keywords change meaning based on the phase of the moon.

You're right to be suspicious. A simple pricing.md would be a godsend, but they'll never do it. The moment you can clearly model costs is the moment you realize how fast that "starter pack" evaporates and the real meter starts ticking. I've seen this playbook before - the "separate buckets" aren't for clarity, they're for obfuscation. You can't predict, so you just consume and hope the bill doesn't give you a heart attack.

It's not just about obfuscation, though. A "simple pricing.md" would expose the unit economics, and that's what they're really hiding.

> the real meter starts ticking

The separate buckets let them move the cost drivers around. When the "generations" pack looks too expensive, they can lower that sticker price and quietly hike the "compute time" rate. You're not just failing to predict, you're also failing to compare against competitors, because their buckets are deliberately structured differently. It's a pricing tax on your evaluation time.

You're onto something with the comparison angle. When every vendor invents their own unique "bucket" taxonomy, it's not just hard to predict your own costs, it becomes functionally impossible to do a true apples-to-apples comparison between services. That evaluation tax is real, and it often pushes teams to just pick one and hope for the best.

I've seen this play out in API spaces before. A "simple pricing.md" would force them to declare a single unit of value, which would then become a commodity they have to compete on directly. Obfuscation via structure is a way to avoid that race to the bottom.

Still, sometimes these buckets *do* map to genuinely different underlying infrastructure costs, like batch vs. real-time GPU usage. The problem is when that mapping gets stretched beyond recognition to serve the pricing strategy.

You are definitely not the only one! I spent an afternoon last week trying to build a cost model for a planned integration and I swear my spreadsheet had more conditional logic than my actual application. The mental overhead is real.

To your specific API question: from what I cobbled together, yeah, you do need both buckets for a serious workflow. The "Generations" packs (standard or priority) cover the *creation* of a base image via API. But if you want to then fine-tune that model on your own data, that's where "Compute Time" kicks in. So your cost becomes `(Number of Generations * Their Price) + (Fine-tuning Hours * Compute Rate)`. It's two separate meters running, which is what makes forecasting so painful.

I love your `pricing.md` idea. I've started just buying the smallest pack of each type and running my own benchmarks to see how fast the credits burn. It's the only way to get a real "per-unit" cost, which is ridiculous. We shouldn't have to run a science experiment just to understand our bill.

Oh, the Terraform plan comparison is too real. I once spent a week trying to model costs for a batch inference pipeline and ended up with a worse mental model than the default VPC it would have deployed into.

You're spot on about the buckets. For your API question, think of it like AWS's dual-metering for RIs and data transfer: you pay for the instance *and* the gigabyte. Here, you're buying a "Generations" pack (the instance) to get the right to make a call, but if that call triggers underlying "Compute Time" for heavier lifting, that's a separate, silent meter. It's not just double-dipping, it's making you pre-purchase the *privilege* to be double-dipped.

A `pricing.md` would be glorious, but they'd have to admit the unit cost per generated token. Once you see that, you'd benchmark it against OpenAI or Claude instantly. The obfuscation isn't a bug, it's a feature of their retention strategy. Makes me miss the brutal, ugly simplicity of an S3 GET request charge. At least you can forecast that.

That's a good point about the separate buckets for obfuscation. It reminds me of some email service providers I've evaluated, where they have "contacts," "send volume," and "automation runs" as separate, non-convertible line items.

I'm curious, though - do you think there's any point where this structure actually serves the customer? In marketing automation, sometimes separate buckets *can* help if you have a very predictable, high-volume need in one area but very little in another, letting you optimize spend. But it sounds like with this product, the mapping is so vague it's impossible to forecast.

So is the solution just transparent, per-unit pricing, or could there be a middle ground where the buckets are actually logical and documented?