Flux 3 Release-Termin: die offizielle Zeitleiste bis jetzt.

Offizielle FLUX 3 Zeitleiste

1. 23. Juli 2026

   FLUX 3 angekündigt

   Black Forest Labs kündigte FLUX 3 als multimodale Modellfamilie an. Eine Ankündigung legt Familie und Richtung fest; sie bedeutet nicht, dass an diesem Tag jede Modalität, jeder Endpunkt oder jeder herunterladbare Checkpoint verfügbar ist.

2. 4. August 2026

   FLUX 3 Video wird allgemein verfügbar

   FLUX 3 Video wurde allgemein verfügbar. Das produktive API-Schema weist den Video-Endpunkt aus, womit dies das erste bestätigte, nutzbare FLUX 3 Produkt-Release ist.

3. 10. August 2026

   Angaben zu Image und Dev bleiben getrennt

   Das offizielle API-Schema listet die FLUX 3 Video-Oberfläche, während der öffentliche Modellkatalog noch kein FLUX 3 Dev-Paket führt. Black Forest Labs hat der öffentlichen Zeitleiste kein eigenes Image-Datum hinzugefügt.

Warum die Formulierung „Flux 3 Release-Termin“ leicht falsch gelesen wird

Modellfamilien erscheinen zunehmend in Etappen. Eine Forschungsankündigung, eine Preview, eine gehostete API, die allgemeine Verfügbarkeit und ein Download offener Gewichte können jeweils eigene Daten haben. Suchergebnisse pressen diese Meilensteine oft in einen einzigen Satz, obwohl jeder eine andere praktische Frage beantwortet. FLUX 3 zeigt das Muster deutlich: Zuerst kam die Ankündigung der Familie, und ein benanntes Video-Produkt erreichte 12 Tage später die allgemeine Verfügbarkeit.

Eine belastbare Antwort braucht deshalb zwei Koordinaten: Modalität und Zugangsart. „FLUX 3 Video über die gehostete API“ hat ein bestätigtes Datum der allgemeinen Verfügbarkeit. Der Image-Zugang wird in offiziellen Mitteilungen gesondert beschrieben, und Dev verlangt den Nachweis eines herunterladbaren Pakets, einer Lizenz, einer Modellkarte und eines Inferenzwegs. Diese Dinge sollten nicht aus dem Video-Endpunkt abgeleitet werden.

Diese Unterscheidung ist für Journalisten, Kreative und Entwickler jeweils aus anderen Gründen wichtig. Journalisten brauchen Daten, die an genaue Aussagen gebunden sind. Kreative müssen wissen, welches Produkt eine Demonstration zeigt. Entwickler brauchen einen Endpunkt oder ein Artefakt, das sie tatsächlich einbinden können. Ein einzelnes Familiendatum ist nützlicher Kontext, aber kein Ersatz für Verfügbarkeitsangaben auf Produktebene.

Was die beiden bestätigten Daten aussagen

Die Lücke von 12 Tagen zwischen der Familienankündigung am 23. Juli und der allgemeinen Verfügbarkeit von Video am 4. August zeigt, dass Black Forest Labs einen benannten Teil der Familie schnell von der Ankündigung in die Produktion bringen kann. Sie begründet keinen 12-Tage-Zeitplan für Image oder Dev. Verschiedene Modalitäten haben verschiedene Anforderungen an Evaluation, Sicherheit, Infrastruktur und Produktreife. Ein Bild-Endpunkt könnte bald folgen, oder das Unternehmen stellt weitere Videofähigkeiten davor.

Das stärkste Release-Signal wird eine Änderung an einer offiziellen Distributionsoberfläche sein, kein Countdown auf einer fremden Website. Für den gehosteten Zugang beobachten Sie das API-Schema von Black Forest Labs auf eine neue Bildroute und eine Modellkennung. Für offene Gewichte beobachten Sie die offizielle Organisationsseite und die Modellkarten auf einen Checkpoint, eine Lizenz, Architekturangaben und Inferenzanforderungen. Ein Social-Post kann eine Absicht ankündigen, aber ein Endpunkt oder eine Modellkarte schafft etwas, das Entwickler tatsächlich einbinden können.

Bis eines dieser Signale auftaucht, bleibt eine genaue Schätzung eine Schätzung. Der schmale Abstand zwischen Ankündigung und Video-GA macht häufiges Beobachten sinnvoll. Er rechtfertigt nicht, ein Kalenderdatum zu erfinden, Vorauszahlungen für ein benanntes, unveröffentlichtes Modell anzunehmen oder unbelegte Spezifikationen zu veröffentlichen.

Wie die offizielle Roadmap zu lesen ist

Eine gestaffelte Verfügbarkeit ist die naheliegendste Lesart der veröffentlichten Fakten. Ein gehostetes Produkt und ein Paket mit offenen Gewichten erfordern unterschiedliche Release-Arbeit. Gehosteter Zugang lässt den Anbieter Kapazität, Versionierung, Sicherheitskontrollen und Updates zentral steuern. Offene Gewichte verlangen einen stabilen Checkpoint, eine Lizenz, eine Modellkarte, einen Referenz-Inferenzweg, die Dateiverteilung und realistische Hardwareangaben. Diese Unterschiede erklären, warum Image-Zugang und Dev-Gewichte als eigenständige Meilensteine verfolgt werden sollten.

Auch die Benennung ist wichtig. Auf eine Familienankündigung können Modalitätsnamen, Stufenbezeichnungen, Preview-Kennungen oder mehrere Endpunkte folgen. Solange Black Forest Labs diese Details nicht veröffentlicht, sollten technische Zusammenfassungen aus einer beschreibenden Formulierung keine geratene Produktkennung machen. Der brauchbare öffentliche Nachweis besteht aus dem genauen Wortlaut, dem Datum, der Zugangsart und der Distributionsoberfläche zu jeder Ankündigung.

Für Kreative bleiben übertragbare Eingaben über alle Release-Stufen hinweg wertvoll: Halten Sie Prompt, Seitenverhältnis, Referenz, gewünschtes Ergebnis und Bewertungsnotizen zusammen. Für Entwickler gilt: Trennen Sie den öffentlichen API-Vertrag von jeder erwarteten Modellbenennung. Für Leser gilt: Bevorzugen Sie datierte offizielle Dokumentation und Repositories des Anbieters gegenüber Countdown-Seiten oder Spezifikationstabellen ohne Quelle.

Was als nächster Meilenstein zählen würde

Für den gehosteten Image-Zugang wäre der stärkste Meilenstein eine anbietereigene API-Route oder ein dokumentiertes Zugangsprogramm mit genauer Kennung, akzeptierten Eingaben, Ausgabeformat, Preisen und Verfügbarkeitsstatus. Eine Warteliste oder Preview kann weiterhin berichtenswert sein, sollte aber als Preview und nicht als allgemeine Verfügbarkeit gekennzeichnet werden.

Für Dev sieht der Nachweis anders aus: ein Repository im Besitz von Black Forest Labs, herunterladbare Dateien, eine Lizenz, eine Modellkarte und ein funktionierender Inferenzweg. Ein gehosteter Image-Zugang würde nicht automatisch ein Release offener Gewichte begründen, ebenso wenig wie eine Familienankündigung automatisch jede Produktoberfläche begründet hat.

Künftige Aktualisierungen dieser Zeitleiste sollten diese Unterscheidungen bewahren. Jede Zeile sollte sich nur ändern, wenn sich die zugehörige offizielle Oberfläche ändert, und jedes Datum sollte auf das Ereignis verweisen, das es beschreibt. So bleibt der Release-Nachweis nützlich, selbst wenn mehrere FLUX 3 Produkte dicht beieinander erscheinen.