Entwicklerstatus · 10.08.2026

Flux 3 API: offizielle Endpunkte und veröffentlichte Preise.

Eine auf Entwickler zugeschnittene Übersicht über die veröffentlichte Flux 3 Video-API, ihre genauen Sekundenpreise, die zugehörigen FLUX.2 Bildreferenzpreise und Integrationsentscheidungen, die anbieterneutral bleiben.

Veröffentlichte API-Preise
Modell oder VorgangAusgabeVeröffentlichter PreisVerfügbarkeit
FLUX 3 Video vollständiges RenderingHD-Video$0.17 pro SekundeAllgemein verfügbar
FLUX 3 Video vollständiges RenderingFHD-Video$0.29 pro SekundeAllgemein verfügbar
FLUX 3 Video EntwurfVideo-Entwurf$0.06 pro SekundeAllgemein verfügbar
FLUX 3 Video VerlängerungHD-Fortsetzung$0.43 pro SekundeAllgemein verfügbar
FLUX.2 pro GenerierungStandbild$0.03 pro BildVerfügbar
FLUX.2 pro BearbeitungBearbeitetes Standbild$0.045 pro BildVerfügbar
FLUX.2 klein 4BStandbild$0.014 pro BildVerfügbar
FLUX.2 klein 9BStandbild$0.015 pro BildVerfügbar
FLUX.2 flexStandbild$0.05 pro BildVerfügbar
FLUX.2 maxStandbild$0.07 pro BildVerfügbar

Was die FLUX 3 API heute umfasst

Das produktive API-Schema von Black Forest Labs enthält eine FLUX 3 Video-Route. Dieser Endpunkt ist die konkrete, allgemein verfügbare Entwickleroberfläche der FLUX 3 Familie mit Stand 10. August 2026. Teams können Video-Workloads anhand der veröffentlichten Sekundenpreise und der verfügbaren Auflösung oder des Entwurfsmodus planen. Die Videoverlängerung wird gesondert mit $0.43 pro Sekunde für die HD-Fortsetzung berechnet.

Dasselbe veröffentlichte Schema führt keine eigene FLUX 3 Route für Standbilder. Die Ankündigung einer multimodalen Familie definiert keine undokumentierten Anfragefelder, Kennungen, Grenzen oder Preise. Entwickler sollten das offizielle Schema als Vertrag behandeln und die Recherche zu einer Standbild-API von der Video-Oberfläche trennen.

Dokumentation und Code sollten diese Unterscheidung bewahren. Öffentliche technische Texte sollten jeden Preis und jede Fähigkeit dem genauen Produkt zuordnen. Integrationscode sollte Produktkennungen und Fähigkeiten als Daten abbilden, statt quer durch Routen und Komponenten auf Marketingnamen der Familie zu verzweigen.

Videokosten verstehen, bevor Sie integrieren

Die Sekundenabrechnung macht die Dauer zu einem erstrangigen Produktregler. Ein vollständiges Rendering von zehn Sekunden kostet $1.70 in HD oder $2.90 in FHD, noch vor Wiederholungen oder Varianten. Ein Entwurf von zehn Sekunden kostet $0.60 und kann nützlich sein, um Bewegung oder Aufbau zu prüfen, bevor ein vollständiges Rendering bezahlt wird. Ein HD-Ergebnis um zehn Sekunden zu verlängern kostet zum veröffentlichten Fortsetzungspreis $4.30.

Diese Beispiele sind einfache Multiplikation, keine zusätzlichen Anbietergebühren. Ein echtes Produkt sollte außerdem verworfene Entwürfe, API-Fehler, Speicherung, Auslieferung, Moderation und Zahlungsabwicklung einkalkulieren. Es sollte Auflösung, Dauer und die daraus folgende Credit- oder Geldbelastung deutlich machen, bevor die Anfrage startet.

Video- und Standbild-Generierung sollten an der Produktgrenze getrennte Auftragsarten bleiben. Dauer, Fortsetzung, Bildrate und Auflösung gehören zum Video; Seitenverhältnis, referenzgeführte Bearbeitung und ausgelieferte Bilddaten gehören zur Standbildarbeit. Beides in eine lose Anfrageform zu pressen, erschwert Validierung, Preisbildung, Verlauf und Fehlerbehandlung.

Der aktuelle Weg zur Bild-API

FLUX.2 pro hat einen veröffentlichten Preis von $0.03 für ein generiertes Bild und $0.045 für eine Bearbeitung. Eine typische asynchrone Bildintegration sendet eine produktspezifische Anfrage mit einem API-Schlüssel, erhält eine Kennung und eine Polling-URL, prüft den Auftrag bis zur Fertigstellung und lädt das Ergebnis herunter, bevor eine temporäre Ausgabe-URL abläuft. Belastbare Dienste speichern ihre Ausgabe selbst, statt eine Anbieter-URL als dauerhafte Auslieferung zu behandeln.

Auf einer credit-basierten Produktebene lassen sich Anbieterkosten auf eine stabile Nutzereinheit abbilden. Eine Anfrage sollte Authentifizierung, verfügbares Guthaben, Promptlänge, Eingabegröße und Ratenbegrenzungen prüfen, bevor sie startet. Der dauerhafte Generierungseintrag und die Credit-Belastung sollten vor der Ausführung im Hintergrund angelegt werden. Schlägt die Anfrage fehl, gibt eine ausgleichende Buchung genau den Credit-Betrag zurück.

Dieses Muster trennt die Produktbuchhaltung vom API-Transport. Synchrones JSON, asynchrones Polling, Base64-Ausgabe und temporäre URLs können alle im selben anbieterneutralen Ergebnis enden: Bilddaten, ein Content-Type, ein dauerhafter Auftragsstatus und ein nachvollziehbares Credit-Ereignis.

Eine Anbieterschicht für einen unbekannten Endpunkt entwerfen

Die künftige Form der FLUX 3 Bildanfrage ist nicht bekannt, daher sollte die Anwendung von der kleinstmöglichen stabilen Fachdaten-Eingabe abhängen: Prompt, Seitenverhältnis, optionale Bilddaten und ein Modellschlüssel. Ein Anbieteradapter übersetzt diese Eingabe in eine Anbieteranfrage und liefert Bilddaten samt Content-Type zurück. Die fachlichen Routen kennen weder die Anbieter-URL noch den Namen der Zugangsdaten.

Ein Modellregister ordnet dem Modellschlüssel Anbieter, Anbieter-Modell-ID, Credit-Preis, Fähigkeiten und Verfügbarkeit zu. Ein veröffentlichtes Modell aufzunehmen wird damit zu einer reinen Datenergänzung — plus einem Anbieteradapter nur dann, wenn der vorhandene Adapter es nicht ausdrücken kann. Oberfläche und API-Route bekommen keine verstreuten Bedingungen wie „wenn FLUX 3, dann sende dieses Feld“.

Diese Grenze erhält auch die Portabilität über Hosting-Plattformen hinweg. Datenbank, Objektspeicher und Umgebungszugriff bei Cloudflare gehören hinter ein Plattformmodul. Ein Wechsel zu einem Node-Adapter und PostgreSQL sollte kein Neuschreiben der Generierungsregeln oder der Seitenkomponenten erfordern.

Prüfliste für den Release-Tag

Bevor Sie einen angeblichen FLUX 3 Image-Endpunkt einbinden, prüfen Sie Quelle, genaue Modell-ID, Authentifizierungsmethode, Content-Types der Anfrage, unterstützte Seitenverhältnisse oder Maße, Grenzen für Eingabebilder, Darstellung der Ausgabe, Polling-Verhalten, Fehlerstruktur, Ratenbegrenzungen, Preis und Bedingungen. Klären Sie, ob der Zugangsstatus Preview, begrenzte Beta oder allgemeine Verfügbarkeit ist.

Lassen Sie repräsentative Briefings laufen statt eines einzelnen Schauprompts. Messen Sie Anweisungstreue, Bewahrung bei Bearbeitungen, Textwiedergabe, Latenz-Perzentile, Fehlerverhalten und Kosten. Laden Sie Ausgabedaten sofort herunter, wenn der Anbieter temporäre Links liefert. Stellen Sie sicher, dass Wiederholungen keine doppelten Abbuchungen oder doppelten Aufträge erzeugen.

Aktualisieren Sie schließlich den öffentlichen Status, die Offenlegung zur Engine, die Preisannahmen und die Vergleichstabelle aus demselben geprüften Nachweis. Ein Launch ist nicht abgeschlossen, wenn sich der Endpunkt ändert, während die Website weiterhin das alte Modell beschreibt.

Was Entwickler in der Wartezeit tun können

Bauen Sie das Produktregister und die Anbieterschnittstelle, ohne eine künftige Kennung zu raten. Speichern Sie Prompts, Seitenverhältnisse, anbieterneutrale Auftragsstatus und Credit-Ereignisse in dauerhaften Strukturen. Halten Sie Polling, Wiederholungen, Authentifizierung und den Umgang mit temporären URLs in den Adaptern. Bereiten Sie Bewertungs-Briefings vor, die echte Produktbedürfnisse abbilden.

Modellieren Sie für Video die ausdrückliche Sekundenökonomie von FLUX 3 Video und setzen Sie die Entwurfsgenerierung bewusst ein. Halten Sie für die Standbild-Recherche die veröffentlichten FLUX.2 Referenzpreise an ihren genauen Produkten fest. Nehmen Sie beim Selbst-Hosting nicht an, dass die Ankündigung einer gehosteten API herunterladbare Gewichte bedeutet.

Diese Vorbereitung macht künftige API-Änderungen kleiner und hält das heutige Verhalten korrekt. Sie ist wertvoller, als Code gegen einen Endpunktnamen oder ein Schema zu schreiben, das nicht veröffentlicht wurde.