Flux 3 release date: the official timeline so far.

Official FLUX 3 timeline

1. July 23, 2026

   FLUX 3 announced

   Black Forest Labs announced FLUX 3 as a multimodal model family. An announcement establishes the family and direction; it does not mean that every modality, endpoint, or downloadable checkpoint is available on that day.

2. August 4, 2026

   FLUX 3 Video reaches GA

   FLUX 3 Video became generally available. The production API schema exposes the video endpoint, making this the first confirmed, usable FLUX 3 product release.

3. August 10, 2026

   Image and Dev guidance remains separate

   The official API schema lists the FLUX 3 Video surface, while the public model catalog does not yet list a FLUX 3 Dev package. Black Forest Labs has not attached a separate Image date to the public timeline.

Why the phrase “Flux 3 release date” is easy to misread

Model families increasingly arrive in stages. A research announcement, a preview, a hosted API, general availability, and an open-weight download can all receive different dates. Search results often compress those milestones into one sentence, even though each one answers a different practical question. FLUX 3 illustrates the pattern clearly: the family announcement came first, and a named Video product reached general availability 12 days later.

A reliable answer therefore needs two coordinates: modality and access type. “FLUX 3 Video through the hosted API” has a confirmed general-availability date. Image access is described separately in official communications, and Dev requires evidence of a downloadable package, license, model card, and inference path. These should not be inferred from the Video endpoint.

That distinction matters to journalists, creators, and developers for different reasons. Journalists need dates tied to exact claims. Creators need to know which product a demonstration covers. Developers need an endpoint or artifact they can actually integrate. A single family date is useful context, but it is not a substitute for product-level availability details.

What the two confirmed dates tell us

The 12-day gap between the July 23 family announcement and the August 4 video GA shows that Black Forest Labs can move a named part of the family from announcement to production quickly. It does not establish a 12-day schedule for Image or Dev. Different modalities have different evaluation, safety, infrastructure, and product-readiness requirements. An image endpoint could follow soon, or the company could sequence more video capabilities before it appears.

The strongest release signal will be a change in an official distribution surface, not a countdown on a third-party site. For hosted access, watch the Black Forest Labs API schema for a new image route and model identifier. For open weights, watch the official organization page and model cards for a checkpoint, license, architecture information, and inference requirements. A social post can announce intent, but an endpoint or model card establishes something developers can actually integrate.

Until one of those signals appears, a precise estimate remains an estimate. The narrow interval between announcement and video GA makes it reasonable to monitor frequently. It does not justify inventing a calendar date, accepting prepayment for a named unreleased model, or publishing unsupported specifications.

How to read the official roadmap

Staged availability is the clearest reading of the published record. A hosted product and an open-weight package require different release work. Hosted access lets the publisher manage capacity, versioning, safety controls, and updates centrally. Open weights require a stable checkpoint, license, model card, reference inference path, file distribution, and realistic hardware guidance. Those differences explain why Image access and Dev weights should be tracked as independent milestones.

Naming also matters. A family announcement may be followed by modality names, tier labels, preview identifiers, or several endpoints. Until Black Forest Labs publishes those details, technical summaries should not turn a descriptive phrase into a guessed product identifier. The useful public record is the exact wording, date, access type, and distribution surface attached to each announcement.

For creators, portable inputs remain valuable across release stages: keep the prompt, aspect ratio, reference, intended output, and evaluation notes together. For developers, separate the public API contract from any expected model naming. For readers, prefer dated official documentation and publisher-owned repositories over countdown pages or unattributed specification tables.

What would count as the next milestone

For hosted Image access, the strongest milestone would be a publisher-owned API route or documented access program with an exact identifier, accepted inputs, output format, pricing, and availability state. A waitlist or preview can still be newsworthy, but it should be labeled as a preview rather than general availability.

For Dev, the evidence is different: a repository owned by Black Forest Labs, downloadable files, a license, a model card, and a working inference path. Hosted Image access would not automatically establish an open-weight release, just as a family announcement did not automatically establish every product surface.

Future updates to this timeline should preserve those distinctions. Each row should change only when the matching official surface changes, and each date should link to the event it describes. That keeps the release record useful even if several FLUX 3 products appear close together.