GPT Image 2 vs Seedream 5.0 Pro vs FLUX.2 Pro: guía de API

Esta comparación no identifica un ganador por calidad respaldado por pruebas. GPT Image 2, Seedream 5.0 Pro y FLUX.2 Pro permiten generar y editar imágenes, pero presentan distintas identidades de modelo, reglas para imágenes de referencia, opciones de enrutamiento, ciclos de vida de las tareas y variables de facturación. Para integrar una API, estas diferencias contractuales suelen importar más que una imagen promocional del proveedor.

La elección práctica depende del flujo de trabajo. GPT Image 2 encaja en una integración directa con OpenAI Images o en un flujo conversacional con Responses. Seedream 5.0 Pro encaja en la ruta de Seedream 5 verificada actualmente en la plataforma conectada, con un contrato de salida restringido y gestión asíncrona de tareas. FLUX.2 Pro encaja en la generación y edición con múltiples referencias mediante la API nativa de BFL, con la posibilidad de elegir entre un endpoint fijo y otro de vista previa que recibe actualizaciones.

Esta guía se revisó el 5 de septiembre de 2026. Utiliza la documentación de OpenAI para GPT Image 2, la documentación de ByteDance y una revisión fechada del catálogo de productos para Seedream 5.0 Pro, y la documentación de Black Forest Labs para FLUX.2 Pro. Ninguna imagen generada, tarea de pago, prueba de latencia o muestra de resultados se utiliza como evidencia.

Conclusiones clave

• Selecciona un modelo o endpoint exacto, no un nombre de familia como «GPT Image», «Seedream 5» o «FLUX.2».
• GPT Image 2 ofrece endpoints de generación y edición, mientras que la Responses API permite flujos de imagen conversacionales y de varios pasos.
• La ruta de Seedream verificada actualmente es seedream-5.0-pro; las rutas genéricas, Lite y Layered con nombres similares no son modelos de API pública intercambiables.
• FLUX.2 Pro admite edición con múltiples referencias y ofrece tanto un endpoint fijo como otro de vista previa que recibe actualizaciones.
• Normaliza los resultados específicos de cada proveedor mediante tu propio estado de tarea, registro de procedencia y revisión de aceptación.
• Compara el coste por recurso aceptado, no un precio copiado de una página ni el coste de una sola solicitud correcta.

Contenido de esta guía

• Comparación de API rápida
• Identidad del modelo y estabilidad de la ruta
• Entradas de generación y edición
• Flujos con imágenes de referencia
• Tareas síncronas y asíncronas
• Verificación de costes
• Evaluación controlada
• Límite del uso comercial
• Preguntas frecuentes

Comparación de API rápida

Las tres integraciones deben compararse como contratos de API, no mediante afirmaciones generales sobre calidad artística. La siguiente tabla recoge lo que pueden demostrar la documentación oficial o la revisión fechada del catálogo.

OpenAI documenta gpt-image-2 como un modelo con entrada y salida de imágenes, disponible mediante endpoints de generación y edición de imágenes. BFL describe FLUX.2 Pro como su opción de generación y edición a escala de producción. ByteDance presenta Seedream 5.0 Pro como un modelo multimodal de generación y edición, pero los controles expuestos por un producto conectado deben verificarse por separado. Consulta la página del modelo de OpenAI, el anuncio de Seedream 5.0 Pro de ByteDance y la descripción general de FLUX.2 de BFL.

Para una guía de selección más amplia dirigida a equipos creativos, consulta la comparación de flujos de trabajo de los tres modelos. Este artículo se centra en los contratos para desarrolladores y los controles operativos.

Identidad del modelo y estabilidad de la ruta

Una integración de producción debe almacenar la identidad exacta del modelo utilizado para cada recurso. Los nombres de familia son útiles para navegar, pero resultan demasiado ambiguos para el enrutamiento, la revisión de regresiones, la conciliación de facturas o el análisis de incidentes.

GPT Image 2 tiene un alias y una versión fechada

OpenAI enumera gpt-image-2 como alias predeterminado y gpt-image-2-2026-04-21 como versión fechada. El alias resulta práctico cuando un equipo quiere utilizar la opción predeterminada actual del proveedor. La versión fechada es más segura cuando un flujo aprobado necesita un comportamiento coherente del modelo entre distintas versiones.

La API de OpenAI Images permite seleccionar directamente el modelo GPT Image. La Responses API funciona de otra forma: la aplicación selecciona un modelo principal compatible con la herramienta de generación de imágenes, y la herramienta gestiona la selección del modelo de imagen subyacente. Esa diferencia debe aparecer en el registro de procedencia. «Generado mediante OpenAI» no es suficientemente preciso para reproducir un resultado. La guía oficial de generación de imágenes explica las dos rutas de API.

Los nombres de Seedream describen actualmente superficies diferentes

El ID del modelo público verificado en la revisión del catálogo del 5 de septiembre fue seedream-5.0-pro. El contrato revisado admitía una salida, hasta 10 imágenes de referencia, opciones de salida de 1K, 1,5K y 2K, y nueve relaciones de aspecto, incluida auto. No exponía parámetros de semilla, prompt negativo ni mejora del prompt.

No recurras de forma silenciosa a seedream-5.0, seedream-5.0-lite o seedream-5.0-pro-layered como sustitutos. El ID genérico tenía una página estática, pero no aparecía en el catálogo de modelos en ejecución revisado. Lite es un modelo original de ByteDance, pero el catálogo público revisado no lo verificó como una ruta activa. La identidad Layered pertenece a un flujo interno del estudio, no a la lista verificada de modelos públicos.

La implementación más segura consiste en incluir seedream-5.0-pro en una lista de permitidos, validarlo durante el despliegue y producir un error claro cuando no esté disponible. Elegir como alternativa el primer modelo de imagen de un catálogo puede devolver una imagen válida de un modelo equivocado. Eso es peor que un error de enrutamiento visible, porque corrompe la procedencia.

Utiliza la página actual del producto Seedream 5.0 Pro y la referencia de la API del modelo como puntos de entrada fáciles de consultar, pero conserva la validación en tiempo de ejecución dentro de la lista de comprobación de la versión.

FLUX.2 Pro separa los endpoints fijo y de vista previa

BFL documenta flux-2-pro como una versión fija y flux-2-pro-preview como el endpoint que recibe primero las mejoras recientes. Ambos utilizan el mismo contrato de API, pero no ofrecen el mismo nivel de control de cambios.

Utiliza el endpoint fijo para cargas de trabajo sensibles a regresiones, plantillas aprobadas y flujos de clientes de larga duración. Evalúa la vista previa en un entorno independiente con un conjunto de pruebas registrado. No permitas que una ruta de vista previa sustituya a una ruta fija por una desviación de la configuración.

La familia FLUX.2 también incluye las variantes Max, Flex, Klein y Dev. Sus capacidades y licencias varían. En particular, las afirmaciones sobre pesos abiertos de algunas variantes Klein no convierten a FLUX.2 Pro en un modelo de pesos abiertos ni autoalojable. La descripción general oficial de FLUX.2 debe prevalecer para cualquier afirmación sobre la familia.

Entradas de generación y edición

La generación y la edición necesitan validaciones de solicitud separadas, porque una edición incluye tanto instrucciones creativas como obligaciones relativas al recurso de origen. El proveedor también puede utilizar otro endpoint, un formato multiparte, un esquema de nombres distinto para las referencias o un método de entrega diferente.

GPT Image 2 admite edición directa y conversacional

La API de OpenAI Images ofrece un endpoint para generación y otro para edición. El endpoint de edición puede modificar una imagen de forma parcial o completa, y la guía oficial documenta la edición con máscara. En gpt-image-2, las entradas de imagen siempre se procesan con alta fidelidad, por lo que la API no admite que el cliente controle el valor de input_fidelity.

Utiliza la Images API cuando una solicitud deba generar o editar una imagen. Utiliza la Responses API cuando la aplicación necesite una conversación iterativa, mantener resultados anteriores en contexto o crear una experiencia de varios pasos. Ambas rutas permiten personalizar propiedades de salida como el tamaño, la calidad, el formato y la compresión, de acuerdo con la compatibilidad actual del modelo.

Un validador de producción debe distinguir, como mínimo, estas entradas:

• solicitud de generación solo con texto
• edición de la imagen completa
• edición con máscara
• edición iterativa que depende de un resultado anterior
• solicitud con uno o varios recursos de referencia

No deduzcas la precisión del texto, la conservación del sujeto ni la localización de la edición a partir de la compatibilidad del endpoint. Son resultados de pruebas de aceptación, no funciones de la API.

Seedream 5.0 Pro expone un contrato conectado más limitado

ByteDance documenta controles originales de Seedream 5.0 Pro como la selección de puntos, la selección con lazo, los bocetos, las referencias de color y material, la fusión de varias imágenes y la separación por capas. Una ruta pública de un modelo no expone automáticamente todos los modos de interacción del proveedor original.

Para la ruta revisada, implementa únicamente los parámetros presentes en el contrato conectado: prompt, URL compatibles de imágenes de referencia, una salida, resoluciones compatibles y relaciones de aspecto admitidas. Rechaza antes de enviar una tarea cualquier opción no compatible de semilla, prompt negativo, múltiples salidas o mejora del prompt.

Para los casos de edición local y capas editables, trata la herramienta de edición local y el flujo de capas de imagen como superficies de producto independientes. La presencia de una herramienta del estudio no demuestra que su modelo interno ni todos sus controles estén disponibles mediante la API pública.

FLUX.2 Pro utiliza la misma familia de modelos para generación y edición

BFL documenta FLUX.2 Pro para generación de texto a imagen y edición de imágenes. Las solicitudes de edición pueden enviar referencias mediante input_image, input_image_2 y los campos numerados posteriores. En la actualidad, BFL documenta hasta 8 imágenes de referencia mediante la API, mientras que su entorno de pruebas admite hasta 10.

La API también documenta prompts estructurados, valores de color exactos, orientación de pose y salidas de hasta 4 megapíxeles. Son controles compatibles o capacidades descritas por el proveedor. No demuestran que todos los prompts vayan a conservar una marca, representar bien una etiqueta o igualar un color objetivo después de la gestión de color posterior.

La guía oficial de edición de FLUX.2 ofrece el patrón actual de solicitud y respuesta de consulta de estado. Para conocer la familia en general, en lugar de sus detalles de implementación, consulta la guía de modelos de imagen FLUX.

Flujos con imágenes de referencia

El número de referencias es solo una restricción. Un flujo fiable con referencias también registra por qué se aportó cada imagen, qué elementos deben conservarse, quién posee sus derechos, cómo se transformó y si el proveedor cobra por procesarla.

Utiliza en la base de datos de tu aplicación un manifiesto de referencias como este:

{
  "role": "product_identity",
  "asset_id": "internal-asset-id",
  "rights_record": "rights-record-id",
  "sha256": "content-hash",
  "must_preserve": ["silhouette", "label", "logo", "base_color"],
  "allowed_changes": ["background", "lighting", "camera_angle"]
}

El hash detecta una sustitución accidental. El registro de derechos vincula la carga con el permiso correspondiente. La lista de elementos que deben conservarse convierte una petición creativa imprecisa en un contrato de aceptación.

Para GPT Image 2, consulta la documentación vigente de Images o Responses para conocer el formato de entrada de la ruta elegida. Para Seedream 5.0 Pro, respeta el límite revisado de 10 URL de referencia y el contrato de una sola salida. Para FLUX.2 Pro, respeta el límite de la API de BFL en lugar de trasladar al código del servidor el límite superior del entorno de pruebas.

No reutilices una URL temporal de salida del proveedor como recurso de origen permanente sin haberla descargado antes en un almacenamiento controlado. La guía de edición de BFL indica que las URL firmadas devueltas solo son válidas durante un periodo limitado, por lo que el proceso debe descargar y verificar el resultado inmediatamente después de que la tarea esté lista.

Tareas síncronas y asíncronas

Las API de los proveedores entregan resultados mediante ciclos de vida diferentes. Normaliza esas diferencias en tu aplicación, en lugar de trasladar tres máquinas de estados distintas a la interfaz de usuario.

Respuesta directa de OpenAI Images

Una llamada directa de generación o edición con OpenAI Images devuelve los datos de la imagen dentro del flujo de solicitud y respuesta. La aplicación puede envolver la llamada en su propia cola para gestionar límites de concurrencia, cancelaciones, reintentos y registros de auditoría, pero esa cola forma parte de tu infraestructura. No es una tarea de imágenes de OpenAI cuyo estado deba consultarse.

Si utilizas la Responses API para un flujo de varios pasos, almacena los identificadores de respuesta y conversación que necesite tu implementación. Registra si la imagen procede de una llamada directa a Images o de una llamada a la herramienta de generación de imágenes.

Consulta de estado para la ruta conectada de Seedream

La ruta de imágenes conectada es asíncrona. Envía la solicitud de generación, conserva el taskId devuelto y consulta el endpoint documentado de la tarea hasta que su estado indique que está lista o que ha fallado. Una recarga de la página no debe hacer que se pierda la identidad de la tarea.

El cliente debe utilizar un retroceso exponencial limitado con variación aleatoria, un plazo total y una gestión explícita de los estados terminales. Un tiempo de espera agotado en la red durante una consulta no demuestra que la generación haya fallado. Reanuda la consulta de la misma tarea antes de valorar el envío de una nueva, pues de lo contrario podrías generar cargos y resultados duplicados.

Consulta mediante la URL devuelta por BFL

Una solicitud de creación de BFL devuelve un ID y una polling_url. Consulta esa URL hasta que el resultado sea Ready, Error o Failed, utilizando los valores terminales exactos de la documentación vigente. Cuando esté listo, recupera el recurso antes de que caduque su URL firmada.

No construyas una URL de consulta a partir de una ruta supuesta cuando la respuesta ya proporciona una. Conserva juntos el ID de solicitud del proveedor, la URL de consulta, la identidad del endpoint y la hora de envío.

Contrato interno normalizado de tareas

La capa de adaptadores puede asignar el comportamiento de los proveedores a un único registro interno:

type ImageJobState =
  | "queued"
  | "running"
  | "ready"
  | "failed"
  | "cancelled"
  | "unknown";

interface ImageJobRecord {
  internalJobId: string;
  provider: "openai" | "seedream-route" | "bfl";
  modelIdentity: string;
  providerRequestId?: string;
  state: ImageJobState;
  submittedAt: string;
  completedAt?: string;
  inputManifestHash: string;
  outputAssetId?: string;
  billableUsage?: Record<string, number>;
  errorClass?: string;
}

Mantén unknown separado de failed. unknown significa que la aplicación no puede determinar en ese momento el estado del proveedor. Reintentar la consulta del estado resulta más seguro que enviar una tarea de sustitución.

Cómo verificar el coste sin publicar precios obsoletos

No fijes en el código una tabla comparativa copiada de las páginas de los proveedores. Los precios de las imágenes cambian y cada proveedor mide unidades facturables diferentes. Una comparación válida de costes comienza con la fuente oficial de precios vigente y termina con tu propio registro de recursos aceptados.

OpenAI documenta la facturación de GPT Image 2 mediante tokens de entrada de texto, entrada de imagen, entrada en caché y salida de imagen. El consumo de tokens de salida cambia con el tamaño y la calidad solicitados, y las solicitudes de edición también incluyen el coste de las entradas de imagen. Utiliza la página de precios de OpenAI y la calculadora de imágenes vigentes el día de la evaluación.

BFL documenta la facturación de FLUX.2 según el modelo y los megapíxeles procesados. Las imágenes de referencia y la resolución de salida influyen en el cálculo, cuyas reglas de redondeo se describen en la página oficial de precios de BFL. Registra la resolución utilizada para cada referencia y salida, en lugar de multiplicar un precio inicial destacado por el número de solicitudes.

Para la ruta conectada de Seedream, utiliza la interfaz de facturación disponible en tiempo real para la cuenta autorizada en el momento de la evaluación. No deduzcas una conversión fija entre puntos, créditos y dólares estadounidenses, ni consideres que una fila de precios visible demuestra que una ruta con un nombre similar esté disponible.

La métrica de producción útil es:

cost per accepted asset =
  (provider charges + retry charges + review labor + correction labor)
  / accepted assets

Almacena estos campos para cada solicitud evaluada:

• fuente de precios y fecha de consulta
• proveedor, identidad exacta del modelo y endpoint
• calidad, dimensiones y número de salidas solicitados
• número de imágenes de referencia y dimensiones procesadas
• uso de texto, imagen y salida cuando se proporcione
• número de reintentos y tareas duplicadas
• cargo del proveedor o débito de la cuenta
• tiempo de revisión y tiempo de corrección
• resultado aceptado, rechazado o aceptado de forma condicional

Este método puede revelar un coste inferior por recurso aceptado sin formular una afirmación universal sobre precios. También permite auditar cambios posteriores en la facturación.

Cómo diseñar una evaluación controlada de las API

Una evaluación controlada debe probar el trabajo que tu aplicación necesita aprobar. No debe comenzar suponiendo que un proveedor es mejor para retratos, texto, realismo o seguimiento del prompt.

Define las tareas a partir de fallos de producción

Construye el conjunto de pruebas con entregables representativos y modos de fallo conocidos. Algunas categorías útiles son la edición con conservación de producto, un gráfico promocional localizado, una composición con múltiples referencias, un gráfico informativo y una edición local dirigida.

Para cada tarea, define requisitos objetivos antes de enviar cualquier solicitud:

• texto e idioma exactos
• relación de aspecto y ubicación final
• recursos de origen y registros de derechos
• elementos que no deben cambiar
• cambios que el modelo puede realizar
• condiciones de rechazo
• correcciones humanas permitidas

Mantén comparables las evidencias

Utiliza los mismos recursos de origen, textos obligatorios, objetivos de salida y criterios de revisión. La sintaxis de cada proveedor puede variar, así que traduce la tarea a los campos admitidos por cada API en lugar de imponer una carga común que no sea válida.

Registra el prompt enviado después de cualquier transformación específica del proveedor. Registra las identidades exactas de los modelos y los tipos de ruta. Si una ruta cambia durante la evaluación, separa los resultados en lugar de combinarlos.

Revisa los resultados sin mostrar las marcas de los modelos

Oculta la identidad del proveedor a los revisores cuando sea posible. Puntúa los defectos objetivos por separado de las preferencias estéticas. Un error ortográfico, una característica de producto ausente, un logotipo modificado o una zona sin editar dañada no deben quedar compensados por una puntuación de estilo alta.

Registra la aceptación al primer intento, los reintentos, el tiempo de revisión, el tiempo de corrección, los errores del proveedor y el coste por recurso aceptado. Formula conclusiones solo para las tareas, entradas, fechas, endpoints y condiciones de cuenta evaluados.

Publica los límites de la evidencia

Un artículo puede indicar que un proveedor documenta una capacidad. También puede afirmar que una evaluación interna fechada observó un resultado cuando están disponibles la metodología y la procedencia. No debe convertir una imagen sin atribución o una ejecución del prompt sin registrar en un ganador por calidad.

Este artículo no incluye resultados de una comparación controlada de modelos, por lo que no formula afirmaciones sobre la calidad relativa de los resultados, la precisión del texto, el realismo de los retratos, la velocidad, la tasa de éxito ni la fiabilidad. La colección de prompts de GPT Image 2 puede ayudar a estructurar un futuro conjunto de tareas, pero los prompts siguen necesitando criterios de aceptación específicos para cada tarea.

El uso comercial sigue estando condicionado

El acceso a la API o un plan de pago no concede automáticamente todos los derechos comerciales para cada material de entrada y salida. La aptitud para uso comercial depende de los términos aplicables de la plataforma y del proveedor, el plan de la cuenta, los derechos sobre las referencias cargadas, el contenido solicitado y los derechos de propiedad intelectual o imagen de terceros.

Antes de utilizar un resultado en publicidad, embalajes, cine, entregas a clientes u otro contexto comercial:

1. Consulta los términos del servicio vigentes y los términos del proveedor correspondiente.
2. Confirma que tienes permiso para cada fotografía, logotipo, imagen personal, personaje, diseño de producto y conjunto de datos cargados.
3. Revisa el resultado para detectar material protegido de terceros, afirmaciones engañosas, contenido restringido y divulgaciones obligatorias.
4. Conserva el prompt, el manifiesto de entradas, la identidad del modelo, la fecha, las pruebas de la cuenta y la aprobación humana.
5. Solicita una revisión jurídica cualificada cuando la campaña, el territorio, el contrato o el tema generen un riesgo importante.

OpenAI publica términos del servicio y políticas de uso para su API, mientras que BFL publica términos independientes para la API y las licencias. Esos documentos pueden cambiar y distintas variantes autoalojadas de FLUX pueden tener licencias diferentes. No traslades una conclusión sobre licencias de una variante a otra.

El acceso de pago no crea automáticamente derechos de propiedad exclusivos, no demuestra que no exista una infracción ni autoriza el uso de todos los recursos de referencia. Esto es una orientación operativa, no asesoramiento jurídico.

Preguntas frecuentes

¿Qué API es la mejor para un nuevo producto de imágenes?

No existe una API universalmente superior. GPT Image 2 es una opción para la generación y edición directas o para un flujo conversacional de OpenAI. Seedream 5.0 Pro es una opción cuando el contrato conectado y verificado encaja en el producto. FLUX.2 Pro es una opción cuando la edición con múltiples referencias mediante BFL y el control de un endpoint fijo encajan en la arquitectura. Realiza una evaluación controlada antes de elegir una opción predeterminada.

¿GPT Image 2, Seedream 5.0 Pro y FLUX.2 Pro son asíncronos de la misma manera?

No. Las llamadas directas a OpenAI Images responden dentro del flujo de la solicitud. La ruta conectada de Seedream devuelve una identidad de tarea cuyo estado debe consultarse. BFL devuelve un ID de solicitud y una URL de consulta. Tu aplicación debe normalizar estos ciclos de vida y conservar tanto el estado original del proveedor como el ID de la solicitud.

¿Puedo enviar el mismo cuerpo de solicitud a los tres proveedores?

No. Sus endpoints, formatos de entrada de imágenes, controles de salida, límites de referencias y respuestas de tareas son diferentes. Utiliza una especificación interna independiente del proveedor y asígnala después, mediante un adaptador validado, a la ruta exacta de cada modelo.

¿Seedream 5.0 Pro expone todos los controles de edición descritos por ByteDance?

No necesariamente. ByteDance documenta las capacidades originales, mientras que un producto conectado puede exponer solo una parte. Utiliza únicamente los parámetros del contrato público vigente y trata las herramientas exclusivas del estudio como superficies independientes.

¿Debo utilizar flux-2-pro o flux-2-pro-preview?

Utiliza flux-2-pro cuando sean importantes la reproducibilidad y el control de cambios. Evalúa flux-2-pro-preview cuando quieras acceder a las mejoras actuales y puedas ejecutar pruebas de regresión. Almacena el endpoint exacto con cada tarea.

¿Cómo debo comparar los costes de generación de imágenes?

Consulta los precios oficiales vigentes en la fecha de la evaluación, registra las entradas facturables que utiliza cada proveedor y calcula el coste por recurso aceptado. Incluye tareas fallidas, duplicados, reintentos, revisión humana y correcciones. No compares precios destacados que presuponen distintas resoluciones o reglas para imágenes de entrada.

¿Se pueden utilizar comercialmente las imágenes generadas?

Es posible. Comprueba el plan activo de la cuenta, los términos del servicio y del proveedor, los derechos sobre las entradas, el contenido del resultado y las restricciones de terceros. El acceso de pago a la API por sí solo no autoriza todos los usos comerciales.

Construye el adaptador antes de elegir un ganador

La decisión de ingeniería defendible no es «¿qué modelo gana?», sino «¿qué ruta exacta satisface este contrato de producto y podemos demostrarlo?».

Define un único esquema interno de tareas y procedencia, valida cada solicitud específica del proveedor, conserva las identidades exactas de los modelos, recupera las tareas con estado desconocido sin reenviarlas a ciegas y concilia los cargos con los recursos aceptados. Después, ejecuta una evaluación controlada con criterios reales de producción.

Ese proceso puede seleccionar rutas distintas para la edición conversacional, la composición con muchas referencias, las ediciones locales y la producción estable por lotes. Una arquitectura multimodelo solo es útil cuando la identidad del modelo, el estado de la tarea, el coste, la evidencia y los derechos permanecen visibles desde la solicitud hasta la aprobación del recurso.

Fuentes oficiales y registro de actualizaciones

Esta comparación volvió a comprobarse el 5 de septiembre de 2026. El límite de la evidencia se reduce a los contratos públicos actuales de los productos, la documentación oficial de los proveedores y una revisión fechada del catálogo de la plataforma. La disponibilidad y los precios pueden cambiar después de esa fecha, por lo que los equipos de producción deben volver a verificarlos antes de una publicación o una decisión de costes.

• OpenAI, referencia del modelo GPT Image 2, consultada el 5 de septiembre de 2026.
• OpenAI, guía de generación de imágenes, consultada el 5 de septiembre de 2026.
• OpenAI, precios de la API, consultados el 5 de septiembre de 2026.
• ByteDance Seed, presentación de Seedream 5.0 Pro, publicada el 8 de julio de 2026 y consultada el 5 de septiembre de 2026.
• Black Forest Labs, descripción general de FLUX.2, consultada el 5 de septiembre de 2026.
• Black Forest Labs, edición de imágenes con FLUX.2, consultada el 5 de septiembre de 2026.
• Black Forest Labs, precios de FLUX.2, consultados el 5 de septiembre de 2026.

El equipo editorial de PixMind se responsabiliza de la revisión del artículo. El sitio actual no muestra un perfil de revisor técnico con nombre propio, por lo que esta página no atribuye a una persona unas credenciales que no puedan verificarse. El paquete final de publicación debe verificar los metadatos canónicos, la portada WebP compartida de 1200 × 630 y los esquemas de artículo y migas de pan generados por el sitio antes de su publicación.