Estado para desarrolladores · 10 de agosto de 2026

API de Flux 3: endpoints oficiales y precios publicados.

Un mapa para desarrolladores de la API publicada de Flux 3 Video, sus precios exactos por segundo, los precios de referencia de imagen de FLUX.2 y las decisiones de integración que conviene mantener neutrales respecto al proveedor.

Precios publicados de la API
Modelo u operaciónSalidaPrecio publicadoDisponibilidad
FLUX 3 Video render completoVideo HD$0.17 por segundoDisponible de forma general
FLUX 3 Video render completoVideo FHD$0.29 por segundoDisponible de forma general
FLUX 3 Video borradorBorrador de video$0.06 por segundoDisponible de forma general
FLUX 3 Video extensiónContinuación en HD$0.43 por segundoDisponible de forma general
FLUX.2 pro generaciónImagen fija$0.03 por imagenDisponible
FLUX.2 pro ediciónImagen fija editada$0.045 por imagenDisponible
FLUX.2 klein 4BImagen fija$0.014 por imagenDisponible
FLUX.2 klein 9BImagen fija$0.015 por imagenDisponible
FLUX.2 flexImagen fija$0.05 por imagenDisponible
FLUX.2 maxImagen fija$0.07 por imagenDisponible

Qué incluye hoy la API de FLUX 3

El esquema de la API de producción de Black Forest Labs incluye una ruta de FLUX 3 Video. Ese endpoint es la superficie concreta y disponible de forma general que la familia FLUX 3 ofrece a los desarrolladores a 10 de agosto de 2026. Los equipos pueden planificar cargas de trabajo de video con los precios por segundo publicados y con la resolución o el modo borrador disponibles. La extensión de video se cobra aparte, a $0.43 por segundo para continuación en HD.

Ese mismo esquema publicado no incluye una ruta propia de imagen fija para FLUX 3. El anuncio de una familia multimodal no define campos de solicitud, identificadores, límites ni precios que no estén documentados. Los desarrolladores deberían tratar el esquema oficial como el contrato y mantener la investigación sobre la API de imagen fija separada de la superficie de Video.

La documentación y el código deberían conservar esa distinción. Los textos técnicos públicos deberían atar cada precio y cada capacidad a su producto exacto. El código de integración debería representar los identificadores y las capacidades de producto como datos, en lugar de ramificar por nombres comerciales de familia repartidos por rutas y componentes.

Entienda el costo del video antes de integrarlo

El precio por segundo convierte la duración en un control de producto de primer orden. Un render completo de diez segundos cuesta $1.70 en HD o $2.90 en FHD, antes de reintentos o variaciones. Un borrador de diez segundos cuesta $0.60 y puede servir para validar el movimiento o la composición antes de pagar un render completo. Ampliar diez segundos un resultado en HD cuesta $4.30 a la tarifa de continuación publicada.

Esos ejemplos son una simple multiplicación, no comisiones adicionales del proveedor. Un producto real debería presupuestar además los borradores abandonados, los fallos de la API, el almacenamiento, la entrega, la moderación y el procesamiento de pagos. Y debería dejar claros la resolución, la duración y el cargo resultante en créditos o en moneda antes de que empiece la solicitud.

La generación de video y la de imagen fija deberían seguir siendo tipos de tarea distintos en la frontera del producto. La duración, la continuación, la velocidad de fotogramas y la resolución son del video; la relación de aspecto, la edición con referencia y los bytes de imagen entregados son del trabajo de imagen fija. Meter ambas cosas en una misma forma de solicitud difusa dificulta razonar sobre la validación, los precios, el historial y el tratamiento de errores.

La vía actual para la API de imagen

FLUX.2 pro tiene un precio publicado de $0.03 por imagen generada y $0.045 por edición. Una integración de imagen asíncrona típica envía una solicitud específica del producto con una clave de API, recibe un identificador y una URL de sondeo, consulta la tarea hasta que está lista y descarga el resultado antes de que caduque cualquier URL de salida temporal. Los servicios duraderos guardan su propia copia del resultado en lugar de tratar la URL del proveedor como una entrega permanente.

En una capa de producto basada en créditos, los costos del proveedor pueden traducirse a una unidad estable para el usuario. Una solicitud debería validar la autenticación, el saldo disponible, la longitud del prompt, el tamaño de la entrada y los límites de frecuencia antes de empezar. La fila duradera de la generación y el cargo en créditos deberían crearse antes de la ejecución en segundo plano. Si la solicitud falla, un asiento compensatorio en el libro devuelve exactamente la misma cantidad de créditos.

Este patrón aísla la contabilidad del producto del transporte de la API. El JSON síncrono, el sondeo asíncrono, la salida en base64 y las URL temporales pueden desembocar todos en el mismo resultado neutral respecto al proveedor: bytes de imagen, un tipo de contenido, un estado de tarea duradero y un evento de crédito rastreable.

Diseñe una capa de proveedor para un endpoint desconocido

No se sabe qué forma tendrá la futura solicitud de imagen de FLUX 3, así que la aplicación debería depender de la entrada de dominio estable más pequeña posible: prompt, relación de aspecto, bytes de imagen opcionales y una clave de modelo. Un adaptador de proveedor traduce esa entrada a una solicitud del proveedor y devuelve los bytes de imagen y un tipo de contenido. Las rutas de negocio no conocen la URL del proveedor ni el nombre de la credencial.

Un registro de modelos asocia la clave de modelo con el proveedor, el identificador de modelo del proveedor, el precio en créditos, las capacidades y la disponibilidad. Añadir un modelo publicado se convierte en añadir datos, más un adaptador de proveedor solo si el existente no puede expresarlo. Ni la interfaz ni la ruta de la API acumulan condiciones dispersas del tipo «si es FLUX 3, envía este campo».

Esta frontera también preserva la portabilidad entre plataformas de alojamiento. La base de datos, el almacenamiento de objetos y el acceso al entorno de Cloudflare quedan detrás de un módulo de plataforma. Pasar a un adaptador de Node y a PostgreSQL no debería obligar a reescribir la política de generación ni los componentes de página.

Lista de verificación para el día del lanzamiento

Antes de integrar un supuesto endpoint de FLUX 3 Image, verifique la fuente, el identificador exacto del modelo, el método de autenticación, los tipos de contenido de la solicitud, las proporciones o dimensiones admitidas, los límites de la imagen de entrada, la representación de la salida, el comportamiento del sondeo, la estructura de errores, los límites de frecuencia, el precio y los términos. Confirme si el estado de acceso es versión preliminar, beta limitada o disponibilidad general.

Lance descripciones representativas en lugar de un único prompt de escaparate. Mida el seguimiento de instrucciones, la conservación en las ediciones, el renderizado de texto, los percentiles de latencia, el comportamiento ante fallos y el costo. Descargue los bytes de salida de inmediato si el proveedor devuelve enlaces temporales. Confirme que los reintentos no generan cargos duplicados ni tareas duplicadas.

Por último, actualice el estado público, la divulgación del motor, los supuestos de precios y la tabla comparativa a partir del mismo registro verificado. Un lanzamiento no está completo si el endpoint cambia mientras el sitio sigue describiendo el modelo anterior.

Qué pueden hacer los desarrolladores mientras esperan

Construya el registro de productos y la interfaz de proveedor sin adivinar un identificador futuro. Guarde los prompts, las proporciones, los estados de tarea neutrales respecto al proveedor y los eventos de crédito en estructuras duraderas. Mantenga el sondeo, los reintentos, la autenticación y el manejo de URL temporales dentro de los adaptadores. Prepare descripciones de evaluación que reflejen necesidades reales del producto.

Para el video, modele la economía explícita por segundo de FLUX 3 Video y use la generación en borrador con criterio. Para investigar imagen fija, mantenga los precios de referencia publicados de FLUX.2 atados a sus productos exactos. Para el autoalojamiento, no dé por hecho que el anuncio de una API alojada implique pesos descargables.

Esta preparación reduce el impacto de los cambios futuros de la API y mantiene exacto el comportamiento actual. Vale más que escribir código contra un nombre de endpoint o un esquema que todavía no se ha publicado.