We resell image generation, so we have to know what a generation costs us before we can price it. That turned out to be a lot harder than reading the pricing page, and the two times it bit us were both cases where a number looked authoritative and was not.
Ratios taken from the published table were off by 2.3x on one tier
The provider charges per token. Tokens per image depend on resolution and on a quality setting, and the pricing page does not list tokens per image. It points you at a calculator in the docs, built from a table of token counts for a 1024×1024 image.
So we took our quality multipliers from that table. Low costs about 0.26 of Medium, High costs about 3.94 of Medium, price accordingly, move on.
To be fair to the provider, that table is not wrong. It describes one configuration, correctly. The mistake was ours: we treated ratios from a single 1024×1024 case as if they were the model's quality multipliers everywhere.
Then we measured. Nine generations, three resolutions, three quality settings, reading the token counts back out of our own usage records:
| derived from the published table | measured | |
|---|---|---|
| low ÷ medium | 0.258 | 0.112 |
| high ÷ medium | 3.94 | 4.00 |
High was close enough. Low cost us less than half of what we had assumed, so we had been pricing our cheapest tier as if it were 2.3 times more expensive than it actually is.
The thing that convinced me the measurement was real and not noise was that the ratios held across resolutions:
low ÷ medium: 0.112, 0.112, 0.111
high ÷ medium: 3.998, 3.999, 3.999
Three different resolutions, same ratio to three decimal places. That is a parameter, not a sample. If those numbers had come back 0.11, 0.19, 0.14 I would have assumed measurement error and kept the published figure.
That is the check I would suggest to anybody doing this. A cost ratio that is stable across conditions you varied is a real multiplier you can build a price on. One that moves around is either noise or evidence that your model has the wrong shape.
A new model version at identical prices can still cost a quarter as much
The second one is stranger, and we caught it before it shipped rather than after.
The provider released a new generation of the same image model. Same price per token on every axis: image input, cached input, text input, output, all identical to the previous generation. Reading the pricing page, there is no change at all.
But the quality tiers went from three named levels to five, and a third-party benchmark on a fixed 2048×1152 image reported:
| output tokens | |
|---|---|
old model, high
|
1,413 |
new model, high
|
367 |
Same tier name, same price per token, about a quarter of the tokens.
I could not reproduce that directly, because at the time we had not integrated the new model. What made me believe it was that it agreed with a number we had measured ourselves for a completely different reason. Our own internal figure was high ÷ medium = 4.00 on the old model. 1,413 ÷ 3.85 lands on 367. So the third-party claim reduces to "the new model's high is roughly the old model's medium", and that is a statement our own independent measurement supports.
Worth being explicit about that reasoning, because it is the only reason I trusted a number I had not produced. A third-party benchmark you cannot reproduce is worth something if it agrees with a ratio you measured yourself for unrelated reasons. It is worth nothing on its own.
The provider did document this, sort of. Their model page says the five quality levels are not direct equivalents of the previous model's levels, and recommends evaluating with your own prompts. That sentence reads like standard hedging. It is actually a spec change with a number attached, and the number is not in it.
Why it matters more if you resell
If you are the end user of the API this is a pleasant surprise. You get the same work for less money, or you move up a tier.
If you resell, it is a trap, and the trap is shaped like a one-line config change.
Our users pick a quality tier and pay accordingly. High costs them four times what Medium costs. That multiple exists because High really did consume about four times the compute.
Swap the model ID to the new generation and nothing else, and the same button still sends quality=high, still charges four times, and now comes back with roughly what Medium used to produce. Nobody sees an error. The image still looks fine. The only thing that changed is that the customer is paying a 4× premium for something that is no longer 4× the work.
That is not a performance regression you can file and get to later. The thing you sold is not the thing you delivered. We ended up leaving the old model on its own row, untouched, and adding the new ones as separate options with their own tiers, measured separately, specifically so that nobody could make that change by editing one field.
The smaller one that nearly got us
Unrelated to models, same category of mistake.
We had a cost baseline that turned out to be wrong, $0.0021 where it should have been $0.00233, and three derived figures computed from it sitting in the same document. Fixing the baseline was a two-character edit. The three derived numbers stayed exactly where they were, looking correct, being wrong. They needed to go 4.7 / 2.4 / 2.2 to 4.3 / 2.1 / 1.9 and they were not going to do that on their own.
Derived numbers do not update themselves. They just keep being confidently wrong in a table somebody will read next quarter.
What we do now
We do not build a cost model on a vendor's published example table. It is illustrative, it is often derived from one configuration, and in our case the ratios taken from it were off by 2.3× on a tier we actually sell. Our own usage records are the only source that describes what we are actually being charged for.
Measure ratios, not absolutes, and vary something while you do it. A multiplier that holds steady across three resolutions is something you can price against. An absolute cost per image is out of date the next time anything changes.
Treat "the tiers are not direct equivalents" as a breaking change, not a disclaimer. Vendors write that sentence in the voice of a footnote.
And if you resell, put a measurement step between "new model is available" and "new model is live", because the config change that skips it is one line and reads as harmless.
We do this for fontvibe.ai, which is where the numbers came from. The reasoning is not specific to images or to any one provider.
