Por qué una imagen costó 1.5 créditos y a 2K, cerca de 1
Una imagen predeterminada costó más que una solicitud a 2K porque el modelo solicitado y el que realmente se ejecutó eran distintos.

Una solicitud de nano_banana_2 con los valores predeterminados me costó 1.5 créditos, mientras que una solicitud de nano_banana_2 a 2K me costó alrededor de 1 crédito.
El trabajo más barato pedía la resolución más alta.
Parece contradictorio si solo conservo el modelo seleccionado en la solicitud y los créditos descontados después. El campo que faltaba era el modelo que realmente se ejecutó.
La solicitud predeterminada no se ejecutó como nano_banana_2. El enrutamiento del servidor la envió a nano_banana_flash. La solicitud a 2K sí se ejecutó como nano_banana_2.
No eran dos trabajos equivalentes con un recargo extraño por resolución. Eran dos solicitudes con el mismo nombre de modelo solicitado que acabaron en modelos de ejecución distintos.
| Modelo solicitado | Ajustes que utilicé | Modelo ejecutado | Coste que pagué |
|---|---|---|---|
nano_banana_2 |
Sin parámetros | nano_banana_flash |
1.5 créditos |
nano_banana_2 |
resolution=2k |
nano_banana_2 |
Alrededor de 1 crédito |
nano_banana_pro |
2K, sin quality=high |
nano_banana_2 |
Alrededor de 1 crédito |
El modelo solicitado no era el modelo ejecutado
Suelo empezar cada entrada de costes con una etiqueta como nano_banana_2. Esa etiqueta describe lo que pedí.
No siempre describe lo que ejecutó el servidor.
En el trabajo con valores predeterminados, la solicitud no contenía parámetros. El campo del modelo ejecutado mostraba nano_banana_flash y el cargo fue de 1.5 créditos.
En el trabajo a 2K, la solicitud incluía explícitamente resolution=2k. El campo del modelo ejecutado seguía siendo nano_banana_2 y pagué alrededor de 1 crédito.
No puedo convertir esos dos trabajos en una fórmula general de precios. Demuestran algo más acotado: el mismo nombre de modelo solicitado no aseguraba el mismo modelo ejecutado, y la solicitud predeterminada no fue la más barata de los dos trabajos medidos.
Eso basta para cambiar lo que registro.
Para cada trabajo necesito al menos tres datos separados: qué solicité, con qué ajustes y qué modelo se ejecutó realmente. El cargo debe ir junto a esos campos, no solo junto al nombre solicitado.
Si escribo únicamente «Nano Banana 2 costó 1.5 créditos», pierdo el dato de que Nano Banana 2 no fue el modelo que realmente se ejecutó en ese trabajo.
Si escribo únicamente «2K costó alrededor de 1 crédito», pierdo el contexto de la solicitud y del enrutamiento que hacía útil la comparación.
«Predeterminado» es una configuración
No incluir parámetros puede parecer la ausencia de una decisión. Aun así, había elegido una configuración de solicitud concreta.
La solicitud sin parámetros produjo una ruta y un cargo. La solicitud explícita a 2K produjo otra ruta y otro cargo.
No lo interpreto como una prueba de que 2K siempre sea más barato. Lo interpreto como una prueba de que no puedo deducir el coste solo a partir de la resolución.
El coste observado correspondía a la configuración completa del trabajo.
Esto importa al comparar pruebas. Si una utiliza ajustes predeterminados y otra especifica 2K, la resolución no es la única diferencia. El modelo ejecutado también puede ser distinto.
Llamar a ambos resultados «el mismo modelo» describiría el campo de la solicitud e ignoraría el de la ejecución.
Así es como una hoja de cálculo aparentemente impecable puede conservar una conclusión equivocada. Dos filas pueden compartir la etiqueta del modelo solicitado y representar resultados de enrutamiento distintos.
El remedio no es una lista de precios expresada con más seguridad. Es un registro de generaciones más completo.
La etiqueta Pro planteó un segundo problema de enrutamiento
La prueba de nano_banana_pro volvió a demostrarlo.
Solicité nano_banana_pro a 2K sin quality=high. El servidor rebajó el trabajo a nano_banana_2. Pagué alrededor de 1 crédito.
La etiqueta solicitada contenía «pro». La ejecutada no.
Eso significa que no puedo citar ese trabajo como una ejecución medida de nano_banana_pro. Es evidencia de una solicitud Pro que se enrutó a nano_banana_2 porque faltaba quality=high.
La distinción se puede borrar fácilmente cuando llega la imagen. El resultado existe, el cargo es visible y el modelo solicitado sigue siendo el nombre familiar. Si no conservo el campo del modelo ejecutado, más adelante puedo recordar erróneamente el resultado como «Pro a 2K cuesta alrededor de 1 crédito».
Eso no fue lo que ocurrió.
Pedí Pro sin el ajuste de alta calidad, el trabajo se ejecutó como Nano Banana 2 y costó alrededor de 1 crédito.
Esa diferencia determina si el trabajo respalda la afirmación de precio que se le atribuye.
Los demás trabajos exigen el mismo registro de costes
Mis otros trabajos de imagen reforzaron la necesidad de conservar la configuración completa.
Una solicitud de soul_2 con un Soul ID, una relación de aspecto de 9:16 y calidad 2K se ejecutó como text2image_soul_v2 y costó 0.12 créditos.
Una solicitud de soul_cinematic a 16:9 y 2K se ejecutó como soul_cinematic y costó alrededor de 1 crédito.
Una solicitud de soul_cast a 16:9 con un ajuste de presupuesto de 50 se ejecutó como soul_cast. Su coste aproximado de 1.5 créditos quedó marcado como supuesto, no medido con la misma certeza.
Una solicitud de soul_location a 16:9 se ejecutó como soul_location. Su coste aproximado de 0.5 créditos se dedujo del cambio de saldo.
Esas etiquetas importan porque el grado de certeza forma parte del dato. Un cargo medido, un coste supuesto y un coste deducido de una variación de saldo no deben presentarse como evidencias equivalentes.
El mismo cuidado se aplica a los demás trabajos de imagen que probé. seedream_v4_5 a 1:1 con calidad básica costó 1 crédito. La edición encadenada con flux_kontext a 1:1 costó alrededor de 1 crédito. gpt_image_2 a 1K con calidad baja se ejecutó como imagegen_2_0 y costó 0.5 créditos. Un trabajo de ms_image a 1K, con calidad baja y un lote de una imagen, costó alrededor de 0.5 créditos. Un trabajo de marketing_studio_image a 1K también costó alrededor de 0.5 créditos.
Estas son las configuraciones que ejecuté y los costes que observé. No autorizan a eliminar los ajustes y publicar un coste universal junto a cada nombre solicitado.
Lo que registro ahora
En cada prueba de imagen guardo el modelo solicitado y el modelo ejecutado en columnas separadas. Conservo junto a ellos la resolución, la calidad, la relación de aspecto y cualquier otro ajuste. Después añado el cargo observado e indico si esa cifra fue medida, supuesta o deducida.
Esa estructura conserva el resultado extraño en lugar de corregirlo para que parezca más intuitivo.
La solicitud predeterminada de nano_banana_2 costó 1.5 créditos porque se ejecutó como nano_banana_flash. La solicitud explícita a 2K costó alrededor de 1 crédito y siguió siendo nano_banana_2. La solicitud Pro sin quality=high también acabó en nano_banana_2.
Añade hoy un campo de «modelo ejecutado» a tu registro de costes de generación de imágenes. La próxima vez que dos solicitudes de modelo aparentemente idénticas produzcan cargos distintos, compara el enrutamiento y los ajustes antes de culpar a la resolución.
Créditos gastados, intentos contados, resultados medidos. Confío en los números porque no halagan a nadie, y a mí menos que a nadie.


