Developer status · August 10, 2026
Flux 3 API: official endpoints and published pricing.
A developer-focused map of the published Flux 3 Video API, its exact per-second prices, related FLUX.2 image reference prices, and integration decisions that remain provider-neutral.
| Model or operation | Output | Published price | Availability |
|---|---|---|---|
| FLUX 3 Video full render | HD video | $0.17 per second | Generally available |
| FLUX 3 Video full render | FHD video | $0.29 per second | Generally available |
| FLUX 3 Video draft | Video draft | $0.06 per second | Generally available |
| FLUX 3 Video extension | HD continuation | $0.43 per second | Generally available |
| FLUX.2 pro generation | Still image | $0.03 per image | Available |
| FLUX.2 pro edit | Edited still image | $0.045 per image | Available |
| FLUX.2 klein 4B | Still image | $0.014 per image | Available |
| FLUX.2 klein 9B | Still image | $0.015 per image | Available |
| FLUX.2 flex | Still image | $0.05 per image | Available |
| FLUX.2 max | Still image | $0.07 per image | Available |
What the FLUX 3 API includes today
The Black Forest Labs production API schema includes a FLUX 3 Video route. That endpoint is the concrete, generally available developer surface of the FLUX 3 family as of August 10, 2026. Teams can plan video workloads using the published per-second prices and the available resolution or draft mode. Video extension is priced separately at $0.43 per second for HD continuation.
The same published schema does not list a separate FLUX 3 still-image route. An announcement for a multimodal family does not define undocumented request fields, identifiers, limits, or prices. Developers should treat the official schema as the contract and keep still-image API research separate from the Video surface.
Documentation and code should preserve that distinction. Public technical writing should attach every price and capability to its exact product. Integration code should represent product identifiers and capabilities in data rather than branch on family marketing names throughout routes and components.
Understand video cost before integrating
Per-second pricing makes duration a first-class product control. A ten-second full render costs $1.70 at HD or $2.90 at FHD before retries or variations. A ten-second draft costs $0.60 and can be useful for validating motion or composition before paying for a full render. Extending an HD result by ten seconds costs $4.30 at the published continuation rate.
Those examples are simple multiplication, not additional provider fees. A real product should also budget for abandoned drafts, API failures, storage, delivery, moderation, and payment processing. It should make resolution, duration, and the resulting credit or currency charge clear before the request begins.
Video and still-image generation should remain separate job types at the product boundary. Duration, continuation, frame rate, and resolution belong to video; aspect ratio, reference editing, and delivered image bytes belong to still-image work. Combining both into one loose request shape makes validation, pricing, history, and error handling harder to reason about.
The current image API path
FLUX.2 pro has a published price of $0.03 for a generated image and $0.045 for an edit. A typical asynchronous image integration submits a product-specific request with an API key, receives an identifier and polling URL, checks the job until it is ready, then downloads the result before any temporary output URL expires. Durable services store their own output rather than treating a vendor URL as permanent delivery.
At a credit-based product layer, vendor costs can map to a stable user unit. A request should validate authentication, available balance, prompt length, input size, and rate limits before starting. The durable generation row and credit charge should be created before background execution. If the request fails, a compensating ledger entry returns the exact credit amount.
This pattern isolates product accounting from API transport. Synchronous JSON, asynchronous polling, base64 output, and temporary URLs can all terminate in the same provider-neutral result: image bytes, a content type, a durable job state, and a traceable credit event.
Design a provider layer for an unknown endpoint
The eventual FLUX 3 image request shape is not known, so the application should depend on the smallest stable domain input: prompt, aspect ratio, optional image bytes, and a model key. A provider adapter translates that input into a vendor request and returns image bytes plus a content type. Business routes do not know the provider URL or credential name.
A model registry maps the model key to provider, vendor model ID, credit price, capabilities, and availability. Adding a released model becomes a data addition plus a provider adapter only if the existing adapter cannot express it. The interface and API route do not gain scattered conditions such as “if FLUX 3, send this field.”
This boundary also preserves portability across hosting platforms. Cloudflare database, object storage, and environment access belong behind a platform module. Moving to a Node adapter and PostgreSQL should not require rewriting generation policy or page components.
Release-day verification checklist
Before integrating a purported FLUX 3 Image endpoint, verify the source, exact model ID, authentication method, request content types, supported ratios or dimensions, input-image limits, output representation, polling behavior, error structure, rate limits, price, and terms. Confirm whether the access state is preview, limited beta, or general availability.
Run representative briefs rather than a single showcase prompt. Measure instruction following, edit preservation, text rendering, latency percentiles, failure behavior, and cost. Download output bytes immediately if the provider returns temporary links. Confirm that retries do not create duplicate charges or duplicate jobs.
Finally, update the public status, engine disclosure, pricing assumptions, and comparison table from the same verified record. A launch is not complete if the endpoint changes while the site continues to describe the old model.
What developers can do while waiting
Build the product registry and provider interface without guessing a future identifier. Store prompts, ratios, provider-neutral job states, and credit events in durable structures. Keep polling, retries, authentication, and temporary URL handling inside adapters. Prepare evaluation briefs that reflect real product needs.
For video, model the explicit per-second economics of FLUX 3 Video and use draft generation deliberately. For still-image research, keep the published FLUX.2 reference prices attached to their exact products. For self-hosting, do not assume that a hosted API announcement implies downloadable weights.
This preparation makes future API changes smaller while keeping current behavior accurate. It is more valuable than writing code against an endpoint name or schema that has not been published.