La página de precios de GPT Image 2.6 resulta tranquilizadora a primera vista: Flare y Sunburst cuestan lo mismo, con la salida de imagen a 30 dólares por millón de tokens, la entrada de imagen a 8 dólares y la entrada de texto a 5 dólares, igual que 2.5.
Antes de actualizar, conviene que los desarrolladores hagan las cuentas de varios puntos que siguen.
Mismo precio unitario, no necesariamente el mismo coste por imagen
En la comunidad de desarrolladores de OpenAI, un desarrollador publicó una muestra comparativa con el mismo prompt: en calidad medium, 2.5 generó 344 tokens y 2.6 generó 1.136.
Calculado a ojo a 30 dólares por millón de tokens, el coste de salida por imagen pasa de aproximadamente 1 céntimo a unos 3,4 céntimos, es decir, 3,3 veces solo en esta partida. Este desarrollador estima que en el nivel low el múltiplo es aún mayor, de unas 4,2 veces, y que de high en adelante queda prácticamente igual.
Es solo una muestra personal y una estimación; OpenAI no ha publicado cifras similares. Lo que sí indica es que, antes de migrar, no basta con mirar la lista de precios. Lo práctico es ejecutar el mismo lote de unos 20 prompts en 2.5 y en 2.6, comparar los tokens de salida de cada imagen y decidir después si se cambia.
Dos cosas que faltan
Batch. Las páginas de los dos modelos 2.6 marcan v1/batch como no compatible. 2.5 Flare todavía puede usar Batch, con un precio de salida que es la mitad del estándar, 15 dólares por millón de tokens. Para quien genera grandes lotes de mapas de bits cada noche, quedarse en 2.5 compensa claramente más.
Instantáneas fijas. Por ahora 2.6 solo tiene la instantánea predeterminada, mientras que 2.5 ofrece versiones con fecha, como gpt-image-2.5-flare-2026-09-08. Para servicios en producción sensibles a la estabilidad de la salida, este punto hay que incluirlo en el cálculo de riesgos.
Cómo usar el nuevo parámetro
El nuevo complexity tiene tres niveles, low, medium y high, y controla cuánta planificación hace el modelo antes de renderizar. Si se omite, el valor predeterminado es high, y ajustarlo no supone un cargo adicional.
El valor predeterminado high es fácil de pasar por alto. La documentación oficial lo deja claro: los valores bajos son adecuados para ediciones acotadas, como cambiar el fondo; los altos ayudan con texto denso y composiciones complejas, pero pueden aumentar la latencia e introducir cambios no deseados. En las interfaces de edición localizada, se recomienda pasar low de forma explícita como punto de partida.
Las limitaciones de las demás novedades, resumidas:
| Función | Uso | Limitaciones |
|---|---|---|
| SVG | output_format: "svg", por el endpoint de generación | n debe ser 1; no admite streaming ni imágenes parciales; el endpoint de edición no puede producir SVG |
| GIF | output_format: "gif", junto con frame_count y frame_duration_ms | Por defecto 9 fotogramas de 200 milisegundos cada uno; el límite de fotogramas aparece en la documentación de dos maneras, 64 y 16 |
| Edición con markup | POST /v1/images/edits, enviando una capa de anotaciones PNG transparente | El ancho y el alto deben coincidir con los de la imagen original; no puede usarse junto con mask ni prompt_rewriter |
Además, antes de usar los modelos GPT Image puede ser necesario completar la verificación de la organización; las cuentas nuevas deben reservar ese plazo.
Cómo interpretar lo dicho sobre velocidad y calidad
«50 % más rápido» y «lo más rápido, unos 6 segundos» son afirmaciones de OpenAI. Un reportaje señala que los 6 segundos corresponden a la configuración de baja calidad de Flare, y que no se han publicado la base de comparación ni el método de medición del 50 %.
Los datos externos son todavía escasos. Según una recopilación de terceros, en la clasificación preliminar de Arena del 4 de noviembre, en texto a imagen, Sunburst tiene 1409 puntos y queda segundo, y Flare tiene 1384 puntos y queda cuarto, ambos en configuración medium; Artificial Analysis aún no tenía entrada para 2.6 en ese momento. Estas posiciones pueden cambiar en unas semanas, así que a la hora de elegir sirven solo como referencia.
También quisimos probar el GIF nativo, pero la herramienta de generación de imágenes integrada de Codex en el equipo local no expone los parámetros de modelo ni de formato de salida; la petición directa solo devolvió un PNG de un único fotograma, y tampoco pudo confirmarse la versión del modelo que había detrás. La animación de carga de esta página tuvo que componerse con una hoja de sprites de seis celdas; la trayectoria de la primera versión salió irregular y se redibujó, aunque el recorrido circular sigue mostrando una ligera deriva.
Si el producto necesita pequeñas animaciones de este tipo, el parámetro GIF de la API o una animación CSS escrita a mano son más controlables que este camino. El método de sprites basta para ilustraciones de contenido, pero para recursos de interfaz aún le falta precisión.
Cómo elegir según el caso
- Generación por lotes cada noche: quedarse primero en 2.5 y usar Batch a mitad de precio.
- Se necesitan iconos vectoriales o animaciones cortas en bucle: son dos capacidades nuevas de 2.6 y se puede migrar solo por ellas.
- Funciones de edición en línea: antes de pasar a Sunburst o Flare, registrar durante una semana los tokens de salida de cada imagen y establecer de forma explícita
complexityyquality. - Diseño y operaciones del equipo necesitan usarlo: no hace falta esperar a que se programe la integración con la API.
Este último caso es muy habitual. Ingeniería sigue haciendo comparativas y esperando la verificación de la organización, mientras que operaciones tiene que entregar imágenes de campaña la semana que viene. Mientras tanto, pueden usar un espacio de trabajo ya hecho, como pixpix.com/gpt-image-2-6, donde se pueden elegir Flare y Sunburst, se usa tras iniciar sesión, y las imágenes de referencia y los ajustes del modelo están dentro del propio espacio. Cobra por créditos y el consumo concreto hay que verlo en el espacio de trabajo; la página del modelo no lista precios ni menciona GIF y SVG, así que resuelve poner en uso primero las imágenes estáticas, y la integración en el producto sigue pasando por la API.
Si operaciones genera primero un lote de necesidades y prompts reales, cuando ingeniería compare 2.5 con 2.6 ya tendrá un conjunto de pruebas listo, más cercano al entorno real que inventar 20 prompts de la nada.
Fuentes: página de modelos y documentación de generación de imágenes de OpenAI, comunidad de desarrolladores de OpenAI, CocoLoop, DEV Community, Kingy AI, Digit; los datos de tokens de la comunidad son una muestra personal y los costes son un cálculo aproximado de esta redacción.