Why a Default Image Cost 1.5 Credits While the 2K Version Cost About 1

A default nano_banana_2 request cost me 1.5 credits, while a nano_banana_2 request at 2K cost about 1 credit.

The cheaper job asked for the higher resolution.

That looks backward if the only fields I keep are the model selected in the request and the credits removed afterward. The missing field was the model that actually ran.

The default request did not execute as nano_banana_2. Server routing sent it to nano_banana_flash. The 2K request did execute as nano_banana_2.

Those were not two equivalent jobs with a strange resolution surcharge. They were two requests with the same requested model name that reached different executed models.

The requested model was not the executed model

I usually begin a cost entry with a label such as nano_banana_2. That label describes what I asked for.

It does not always describe what the server ran.

In the default job, the request contained no parameters. The executed-model field showed nano_banana_flash, and the charge was 1.5 credits.

In the 2K job, the request explicitly included resolution=2k. The executed-model field remained nano_banana_2, and I paid about 1 credit.

I cannot turn those two jobs into a general pricing formula. They establish a narrower point: the same requested model name did not guarantee the same executed model, and the default request was not the cheaper of the two measured jobs.

That is enough to change what I log.

For each job, I need at least three separate facts: what I requested, what settings went with it, and what model actually executed. The debit belongs beside those fields, not beside the requested name alone.

If I write only “Nano Banana 2 cost 1.5 credits,” I lose the fact that Nano Banana 2 was not the model that actually executed for that job.

If I write only “2K cost about 1 credit,” I lose the request and routing context that made the comparison useful.

“Default” is a configuration

No parameters can look like the absence of a decision. Even so, I had made a distinct request configuration.

The unparameterized request produced one route and one charge. The explicit 2K request produced another route and another charge.

I do not read that as proof that 2K is always cheaper. I read it as proof that I cannot infer cost from resolution alone.

The observed cost belonged to the full job configuration.

This matters when comparing tests. If one test uses default settings and another specifies 2K, the resolution is not the only difference. The executed model may differ too.

Calling both outputs “the same model” would describe the request field while ignoring the execution field.

That is how a clean-looking spreadsheet can preserve the wrong lesson. Two rows may share a requested label but represent different routing outcomes.

The remedy is not a more confident price list. It is a more complete generation log.

The Pro label created a second routing problem

The nano_banana_pro test made the point again.

I requested nano_banana_pro at 2K without quality=high. The server downgraded the job to nano_banana_2. I paid about 1 credit.

The requested label contained “pro.” The executed label did not.

That means I cannot cite that job as a measured nano_banana_pro execution. It is evidence about a Pro request that was routed to nano_banana_2 because quality=high was absent.

This distinction is easy to erase after the image arrives. The output exists, the debit is visible, and the requested model remains familiar. If I do not retain the executed-model field, I can later misremember the result as “Pro at 2K costs about 1 credit.”

That is not what happened.

I requested Pro without the high-quality setting, the job executed as Nano Banana 2, and it cost about 1 credit.

The difference determines whether the job can support the price claim being attached to it.

The other jobs require the same accounting

My other image jobs reinforced the need to preserve the complete configuration.

A soul_2 request with a Soul ID, a 9:16 ratio, and 2K quality executed as text2image_soul_v2 and cost 0.12 credits.

A soul_cinematic request at 16:9 and 2K executed as soul_cinematic and cost about 1 credit.

A soul_cast request at 16:9 with a budget setting of 50 executed as soul_cast. Its roughly 1.5-credit cost was marked as assumed, not measured with the same certainty.

A soul_location request at 16:9 executed as soul_location. Its roughly 0.5-credit cost was inferred from the balance change.

Those labels matter because the confidence level is part of the fact. A measured charge, an assumed cost, and a cost inferred from a balance delta should not be presented as identical evidence.

The same care applies to the other image jobs I tested. seedream_v4_5 at 1:1 with basic quality cost 1 credit. flux_kontext chain editing at 1:1 cost about 1 credit. gpt_image_2 at 1K with low quality executed as imagegen_2_0 and cost 0.5 credits. An ms_image job at 1K, low quality, and a batch of one cost about 0.5 credits. A marketing_studio_image job at 1K also cost about 0.5 credits.

These are the configurations I ran and the costs I observed. They are not permission to strip the settings away and publish a universal cost beside each requested name.

What I record now

For every image test, I keep the requested model and executed model in separate columns. I keep resolution, quality, ratio, and any other setting beside them. Then I add the observed debit and mark whether that figure was measured, assumed, or inferred.

That structure preserves the strange result instead of correcting it into something more intuitive.

The default nano_banana_2 request cost 1.5 credits because it executed as nano_banana_flash. The explicit 2K request cost about 1 credit and remained nano_banana_2. The Pro request without quality=high also landed on nano_banana_2.

Add an “executed model” field to your image-generation cost log today. The next time two apparently identical model requests produce different charges, compare routing and settings before blaming resolution.

---

Credits spent, attempts counted, results measured. I trust numbers because they don't flatter anybody, least of all me.