API Flux 3 : endpoints actuels, accès et tarifs officiels

Tarifs d’API publiés
Modèle ou opération	Sortie	Prix publié	Disponibilité
FLUX 3 Video, rendu complet	Vidéo HD	$0.17 la seconde	Disponibilité générale
FLUX 3 Video, rendu complet	Vidéo FHD	$0.29 la seconde	Disponibilité générale
FLUX 3 Video, brouillon	Brouillon vidéo	$0.06 la seconde	Disponibilité générale
FLUX 3 Video, extension	Prolongation HD	$0.43 la seconde	Disponibilité générale
FLUX.2 pro, génération	Image fixe	$0.03 par image	Disponible
FLUX.2 pro, retouche	Image fixe retouchée	$0.045 par image	Disponible
FLUX.2 klein 4B	Image fixe	$0.014 par image	Disponible
FLUX.2 klein 9B	Image fixe	$0.015 par image	Disponible
FLUX.2 flex	Image fixe	$0.05 par image	Disponible
FLUX.2 max	Image fixe	$0.07 par image	Disponible

Ce que l’API FLUX 3 comprend aujourd’hui

Le schéma d’API de production de Black Forest Labs comprend une route FLUX 3 Video. Cet endpoint est la surface développeur concrète et généralement disponible de la famille FLUX 3 au 10 août 2026. Les équipes peuvent planifier des charges vidéo à partir des prix publiés à la seconde et du choix de résolution ou du mode brouillon. L’extension vidéo est facturée à part, à $0.43 la seconde pour une prolongation HD.

Ce même schéma publié ne liste aucune route FLUX 3 distincte pour l’image fixe. L’annonce d’une famille multimodale ne définit ni champs de requête, ni identifiants, ni limites, ni prix non documentés. Les développeurs devraient traiter le schéma officiel comme le contrat et garder la veille sur l’API d’image fixe séparée de la surface Video.

La documentation et le code devraient préserver cette distinction. Les écrits techniques publics devraient rattacher chaque prix et chaque capacité à son produit exact. Le code d’intégration devrait représenter identifiants et capacités de produit sous forme de données, plutôt que de brancher sur des noms marketing de famille dans les routes et les composants.

Comprendre le coût vidéo avant d’intégrer

Une facturation à la seconde fait de la durée un réglage produit de premier plan. Un rendu complet de dix secondes coûte $1.70 en HD ou $2.90 en FHD, avant toute reprise ou variante. Un brouillon de dix secondes coûte $0.60 et peut servir à valider le mouvement ou la composition avant de payer un rendu complet. Prolonger de dix secondes un résultat HD coûte $4.30 au tarif de prolongation publié.

Ces exemples sont de simples multiplications, sans frais supplémentaires du prestataire. Un produit réel devrait aussi budgéter les brouillons abandonnés, les échecs d’API, le stockage, la diffusion, la modération et le traitement des paiements. Il devrait rendre clairs la résolution, la durée et le montant en crédits ou en devise qui en découle, avant le lancement de la demande.

La génération vidéo et la génération d’images fixes devraient rester deux types de tâches distincts à la frontière du produit. Durée, prolongation, cadence d’images et résolution relèvent de la vidéo ; format d’image, retouche par référence et octets d’image livrés relèvent du travail d’image fixe. Fondre les deux dans une même forme de requête approximative rend la validation, la tarification, l’historique et la gestion des erreurs plus difficiles à raisonner.

Le chemin actuel de l’API image

FLUX.2 pro affiche un prix publié de $0.03 pour une image générée et $0.045 pour une retouche. Une intégration d’image asynchrone typique envoie une requête propre au produit avec une clé d’API, reçoit un identifiant et une URL d’interrogation, vérifie la tâche jusqu’à ce qu’elle soit prête, puis télécharge le résultat avant l’expiration de toute URL de sortie temporaire. Les services durables stockent leur propre sortie au lieu de traiter une URL fournisseur comme une livraison permanente.

Au niveau d’un produit fondé sur des crédits, les coûts fournisseur peuvent se ramener à une unité utilisateur stable. Une requête devrait valider l’authentification, le solde disponible, la longueur du prompt, la taille de l’entrée et les limites de débit avant de démarrer. La ligne de génération durable et le débit de crédits devraient être créés avant l’exécution en arrière-plan. Si la demande échoue, une écriture compensatoire au registre restitue le montant exact en crédits.

Ce schéma isole la comptabilité produit du transport de l’API. JSON synchrone, interrogation asynchrone, sortie en base64 et URL temporaires peuvent tous aboutir au même résultat indépendant du prestataire : des octets d’image, un type de contenu, un état de tâche durable et un événement de crédit traçable.

Concevoir une couche prestataire pour un endpoint inconnu

La forme que prendra la requête d’image FLUX 3 n’est pas connue : l’application devrait donc dépendre de la plus petite entrée métier stable — prompt, format d’image, octets d’image facultatifs et clé de modèle. Un adaptateur de prestataire traduit cette entrée en requête fournisseur et renvoie des octets d’image plus un type de contenu. Les routes métier ignorent l’URL du prestataire et le nom des identifiants.

Un registre de modèles associe la clé de modèle au prestataire, à l’identifiant de modèle chez le fournisseur, au prix en crédits, aux capacités et à la disponibilité. Ajouter un modèle sorti devient un ajout de données, plus un adaptateur de prestataire uniquement si l’adaptateur existant ne sait pas l’exprimer. L’interface et la route d’API ne se remplissent pas de conditions éparpillées du type « si FLUX 3, envoyer ce champ ».

Cette frontière préserve aussi la portabilité entre plateformes d’hébergement. Base de données, stockage objet et accès à l’environnement chez Cloudflare doivent rester derrière un module de plateforme. Passer à un adaptateur Node et à PostgreSQL ne devrait pas obliger à réécrire la politique de génération ni les composants de page.

Liste de vérification le jour de la sortie

Avant d’intégrer un prétendu endpoint FLUX 3 Image, vérifiez la source, l’identifiant de modèle exact, la méthode d’authentification, les types de contenu acceptés, les formats ou dimensions pris en charge, les limites d’image d’entrée, la représentation de sortie, le comportement d’interrogation, la structure des erreurs, les limites de débit, le prix et les conditions. Confirmez si l’état d’accès est une préversion, une bêta limitée ou une disponibilité générale.

Lancez des briefs représentatifs plutôt qu’un seul prompt de vitrine. Mesurez le respect des instructions, la préservation lors des retouches, le rendu du texte, les centiles de latence, le comportement en cas d’échec et le coût. Téléchargez immédiatement les octets de sortie si le prestataire renvoie des liens temporaires. Vérifiez que les reprises ne créent ni double facturation ni tâches en double.

Enfin, mettez à jour l’état public, la mention du moteur, les hypothèses tarifaires et le tableau de comparaison à partir du même relevé vérifié. Un lancement n’est pas achevé si l’endpoint change pendant que le site continue de décrire l’ancien modèle.

Ce que les développeurs peuvent faire en attendant

Construisez le registre de produits et l’interface de prestataire sans deviner un futur identifiant. Stockez les prompts, les formats, les états de tâche indépendants du prestataire et les événements de crédit dans des structures durables. Gardez l’interrogation, les reprises, l’authentification et la gestion des URL temporaires à l’intérieur des adaptateurs. Préparez des briefs d’évaluation qui reflètent de vrais besoins produit.

Pour la vidéo, modélisez explicitement l’économie à la seconde de FLUX 3 Video et servez-vous délibérément de la génération brouillon. Pour la veille sur l’image fixe, gardez les prix FLUX.2 publiés rattachés à leurs produits exacts. Pour l’auto-hébergement, ne supposez pas qu’une annonce d’API hébergée implique des poids téléchargeables.

Cette préparation réduit l’ampleur des changements d’API futurs tout en gardant le comportement actuel exact. Elle vaut mieux qu’écrire du code contre un nom d’endpoint ou un schéma qui n’a pas été publié.