GPT-Image-2.6 vs GPT-Image-2.5: el cambio es una sola cadena; la factura, no

Migrar de GPT-Image-2.5 a GPT-Image-2.6 es, a nivel de API, la actualización menos espectacular que OpenAI ha lanzado en todo el año. Los mismos dos endpoints, la misma lista de precios, la misma división Flare frente a Sunburst. Cambia la cadena del modelo y nada más tiene que cambiar. Esa es también la trampa. GPT-Image-2.6 añade un parámetro que GPT-Image-2.5 nunca tuvo —un control de complejidad— y omitirlo no lo desactiva. Su valor predeterminado es alto. Un pipeline que cambia la cadena y lo despliega no está comprando la misma cantidad de trabajo por la misma cantidad de dinero; está comprando más trabajo, y por eso el primer informe de costos después de una migración puede cambiar aunque las tarifas publicadas no lo hayan hecho.

Ambos modelos alcanzaron la disponibilidad general con las mismas condiciones comerciales, y eso es lo que hace que esta comparación sea inusual. No hay ninguna discusión de precios que mantener. La discusión gira enteramente en torno a dónde se destina el nuevo trabajo y a si tu tráfico está configurado de modo que se beneficie.

La superficie de la API es realmente una sustitución directa — con un solo hueco.

OpenAI lanzó GPT-Image-2.6 el 4 de noviembre de 2026 como dos modelos de API en lugar de uno, heredando la estructura que estableció con la 2.5. La gama orientada al detalle y la consistencia es GPT-Image-2.6 Sunburst; la gama de velocidad es GPT-Image-2.6 Flare. Sus predecesores, GPT-Image-2.5 Sunburst y GPT-Image-2.5 Flare, conservan los mismos nombres y la misma relación entre sí.

• Cadenas de modelo — gpt-image-2.6-flare y gpt-image-2.6-sunburst sustituyen a gpt-image-2.5-flare y gpt-image-2.5-sunburst, con la misma lógica de nombres: uno para latencia y otro para detalle.

• Puntos de conexión — /v1/images/generations y /v1/images/edits, sin cambios. No hay ningún punto de conexión nuevo que integrar.

• Tarifas — $5 por millón de tokens de entrada de texto, $8 por millón de tokens de entrada de imagen, $30 por millón de tokens de salida de imagen, con entrada en caché a $1.25 y $2.00. Idéntico byte por byte a 2.5.

• Niveles de calidad — bajo, medio, alto, xhigh, max y auto. La misma escala.

• Tamaños recomendados: 1024×1024, 1536×1024 y 1024×1536 siguen encabezando la documentación, con dimensiones personalizadas aceptadas en múltiplos de 16 y relaciones de aspecto de 1:3 a 3:1.

• El vacío — 2.6 no está disponible mediante la Batch API. Si tu gasto en imágenes depende de un trabajo nocturno a mitad de precio, ese trabajo todavía no puede moverse.

Esa última línea es la que realmente rompe algo. Todo lo anterior es un reemplazo de cadenas y una ejecución de regresión. La brecha de lotes es un bloqueo arquitectónico justamente para las cargas de trabajo —catálogos masivos, recargas nocturnas, generación de A/B a gran escala— en las que un descuento del 50 % es la razón misma por la que la carga de trabajo existe.

El dial de complejidad es la verdadera característica, y su valor predeterminado es la sorpresa.

La complejidad es un nuevo eje que se sitúa junto a la calidad, no dentro de ella, y la distinción importa más de lo que parece. La calidad controla el renderizado: cuántos tokens de salida se destinan a la imagen. La complejidad controla la planificación: cuánto razona el modelo antes de empezar a renderizar. Puedes pedir una imagen de baja calidad de una escena complicada, o una imagen de alta calidad de una escena sencilla, y en la 2.6 esas son peticiones genuinamente separadas.

La documentación es explícita en que omitir el parámetro hace que se establezca por defecto en high. Por lo tanto, quien llama y migra una solicitud de 2.5 cambiando solo el nombre del modelo y nada más está optando silenciosamente por el presupuesto máximo de planificación en cada llamada. Eso no es un error —es el valor predeterminado sensato para un modelo cuyo argumento de venta es pensar más—, pero sí significa que el primer mes de tráfico de 2.6 no es una comparación equivalente con el último mes de tráfico de 2.5.

Hay al menos un dato público que apunta en la misma dirección. Una prueba práctica con tres imágenes publicada el 4 de noviembre informó $0.1245 de salida de 2.6 frente a $0.0446 para las mismas imágenes fijas en 2.5 — aproximadamente el triple, con una tarifa que no cambió. Tres imágenes no son un benchmark y no deberían citarse como tal; la muestra es demasiado pequeña para establecer un multiplicador. Lo que sí hace es demostrar el mecanismo, y el mecanismo está documentado: más tokens de planificación por solicitud, activados por defecto, facturados a $30 por millón.

Si adoptas un solo paso operativo de este artículo, que sea este. Configura la complejidad de forma explícita —medio es una primera estimación razonable para igualar el comportamiento de la era 2.5— y luego mide los tokens de salida por solicitud antes y después. No midas dólares por solicitud. Los dólares por solicitud te dirán que la tabla de tarifas no cambió, lo cual ya sabías. Los tokens por solicitud te dirán si el modelo está haciendo más trabajo del que le pediste.

Dónde se aplica realmente la mejora de velocidad del 50 % prometida

OpenAI describe GPT-Image-2.6 como aproximadamente un 50 % más rápido en general, pero las cifras por nivel son mucho más interesantes que el titular, y son cifras del propio proveedor, no medidas de forma independiente. Se informa que Flare es aproximadamente 2,6× su predecesor, y los renderizados de baja calidad se completan en tan solo seis segundos. Se informa que Sunburst es aproximadamente 1,15×.

Esos dos números describen dos mejoras completamente diferentes. Si tu pipeline ejecuta Flare para la iteración —exploración de miniaturas, ajuste de prompts, cualquier cosa en la que una persona esté esperando el resultado—, 2.6 supone un cambio radical y la migración se amortiza solo con la atención. Si tu pipeline ejecuta Sunburst para la calidad del resultado final, una mejora del 15 % en la latencia está dentro del margen de ruido entre ejecuciones de la mayoría de las configuraciones de hosting, y la velocidad no es motivo alguno para migrar.

Vale la pena señalarlo con honestidad: la misma pequeña prueba práctica que informó la inflación de tokens también informó que 2.6 era más lento que 2.5 en sus tres imágenes, lo que contradice la afirmación del proveedor. Con n=3 eso es ruido, no una refutación. Pero es un recordatorio de que "50% más rápido" es un agregado de presentación de lanzamiento entre niveles de calidad, y un pipeline real ve un solo nivel con una única configuración de calidad.

Nadie ha alcanzado 2.6 todavía, y 2.5 sigue en primer lugar.

Esta es la parte de la comparación que la mayoría de la cobertura está pasando por alto. Artificial Analysis, al ejecutar sus paneles AA-Image-T2I v2.1 y de edición, no tenía ninguna fila para GPT-Image-2.6 cuando se consultó el 5 de noviembre de 2026. No una puntuación baja: ninguna fila.

Lo que esas tablas sí muestran es que el modelo que se está reemplazando sigue ganándolas:

• Texto a imagen — GPT-Image-2.5 Sunburst (max) 1.224 Elo de 13.153 votos, primero. GPT-Image-2.5 Flare (max) 1.207 de 12.498, segundo. GPT Image 2 (high) 1.188, tercero.

• Edición de imágenes — GPT-Image-2.5 Sunburst (max) 1.200 de 18.370 votos, primero. GPT-Image-2.5 Flare (max) 1.183 de 19.259, tercero por detrás de MAI-Image-2.7-Preview con 1.197.

El material de lanzamiento de OpenAI cita Design Arena para un primer puesto de 2.6 Sunburst. Esa es una afirmación real en un tablero real, pero es un conjunto de evaluadores distinto en una escala distinta, y que un proveedor elija el tablero que favorece su lanzamiento no es evidencia de nada que un comprador pueda usar. El dato comparable, de terceros y votado para 2.6 aún no existe. Hasta que exista, la postura defendible es que 2.5 es el modelo de imagen con la puntuación independiente más alta en ambos tableros principales y que 2.6 no está probado: mejor en las formas específicas en que OpenAI dice que es mejor, y sin medir en todo lo demás.

Una migración que se hace en una tarde

El cambio es lo bastante barato como para que el enfoque sensato no sea una migración de golpe, sino una gradual, ejecutada con tus propios prompts en lugar del conjunto de prompts de referencia de cualquier otro.

Empieza fijando la complejidad en un valor que hayas elegido tú, para que el cambio sea un cambio que hiciste tú y no uno que llegó por defecto. Después, vuelve a ejecutar un par de cientos de prompts reales de tus registros de producción —no los prompts limpios de tus fixtures de prueba, sino los desordenados, con erratas y relaciones de aspecto incómodas—. Compara dos números: tokens de salida por imagen aceptada e imágenes aceptadas por cada cien intentos. El segundo es donde se reflejaría una mejora de consistencia, y es el número que determina de verdad si la actualización ahorra dinero, porque una imagen que descartas cuesta el presupuesto completo de tokens y no devuelve nada.

Mantén una ruta de respaldo a 2.5 para el trabajo por lotes, ya que 2.6 todavía no puede atenderlo. Y trata cualquier tráfico de Sunburst como una cuestión de calidad más que de velocidad: si la tasa de aceptación no cambia, habrás comprado una mejora del 15 % en latencia y una factura de planificación más grande.

Cuándo permanecer en 2.5 es la respuesta correcta

Hay tres casos que están lo bastante claros como para nombrarlos. Las cargas de trabajo por lotes deberían quedarse, porque la versión 2.6 no está en la Batch API y la 2.5 sí. Los pipelines de calidad de Sunburst deberían quedarse a menos que la prueba de tasa de aceptación indique lo contrario, porque una aceleración de 1,15× no compensa un cambio en el modelo de costes. Y cualquiera cuya tasa de aceptación actual ya sea aceptable debería quedarse, porque las nuevas capacidades —exportación a SVG, GIF animado, edición guiada por marcado— son funciones adicionales, no mejoras de calidad, y solo las necesita si tiene un entregable que las requiera.

La actualización es real. Solo que se concentra en la latencia de Flare y en nuevos formatos de salida, y eso es más limitado de lo que sugiere "un nuevo modelo".

Disponibilidad y la incómoda forma de una migración dividida

OrcaRouter ofrece GPT-Image-2.5 Flare y GPT-Image-2.5 Sunburst hoy a precio de lista con 0 % de recargo, por lo que la tarifa del proveedor es la tarifa que usted paga, sin ningún margen añadido. GPT-Image-2.6 no figura en el catálogo a fecha de 5 de noviembre de 2026 —un día después de su lanzamiento—, lo que convierte el problema práctico inmediato en uno de enrutamiento y no de modelado: durante la comparativa, el tráfico de 2.5 se ejecuta con una clave y conmutación por error automática, mientras que el tráfico de 2.6 va directamente a OpenAI bajo un segundo contrato y una segunda factura.

Esa diferencia conviene planificarla en lugar de descubrirla. Consulta el catálogo antes de comprometer una ruta de producción con 2.6, porque la paridad el día de lanzamiento no es algo que ningún enrutador pueda prometer con un modelo que tiene veinticuatro horas. Cuando llegue, la regla de paso directo significa que la tarifa del proveedor es la que pagas ese mismo día —un cambio de precio por parte de OpenAI llegaría sin una renegociación por nuestra parte—, pero hasta entonces, la lectura honesta de la situación es que 2.5 es enrutable y 2.6 no.

Lo cual es otro argumento a favor de una migración del tamaño de una tarde en lugar de una del tamaño de un fin de semana. Pasa la 2.5 por el enrutador, mantén estable tu línea base de costos y añade la 2.6 detrás de un flag una vez que hayas medido qué efecto tiene el valor predeterminado de complejidad en tus recuentos de tokens. El modelo no va a desaparecer, y el endpoint por lotes llegará antes de que lo haga tu próximo ciclo de planificación trimestral.