FLUX 3 Image Pricing: Choose Resolution by Delivery Size

FLUX 3 Image pricing is determined by the resolution tier you request. The practical choice is the smallest tier that survives your final crop, layout and delivery checks. Increasing resolution across every attempt can spend more on rejected concepts than on the images you actually use.

The current rate table below was checked on October 15, 2026. The budget examples use synthetic production quantities and executed arithmetic; they do not measure FLUX image quality or generation speed.

Current FLUX 3 Image prices by resolution

Black Forest Labs' live pricing page lists these API rates for FLUX 3 Image:

Prices are per generated image, checked October 15. The provider charges the requested tier across its supported aspect ratios. Prompts and permitted reference images are included. Its pricing notes say failed, rejected and moderation-withheld generations are not billed. The table excludes enterprise agreements and downstream editing, storage or delivery expenses. Current rate and billing notes

An old discount is a poor basis for a new purchase order. Save the selected model, tier, displayed rate and date when approving a budget. If a reseller serves FLUX, use that reseller's invoice contract rather than copying BFL's direct API prices into its cost sheet.

Translate the tier into the image you will deliver

“4K” is a tier label, not a promise that every aspect ratio produces the same width and height. BFL describes approximate pixel areas for its tiers and notes that dimensions can be rounded. Read the delivered width and height before choosing a crop. FLUX pricing notes

Start with the asset specification. A website card, a wide hero and a portrait campaign creative have different composition constraints even if they depict the same product. Record the final aspect ratio, displayed dimensions, crop allowance and any details that must remain legible. Price the generation against that specification.

For a synthetic 1600 × 900 hero, the delivery area is 1,440,000 pixels. That calculation describes the web asset only; it does not automatically select a particular provider tier. A source with sufficient total pixels can still lose a logo or face when cropped. A source with the right framing can still be soft after resizing. Review the image in the actual layout, including the mobile crop, before accepting it.

Separate concept approval from delivery approval. Concept approval asks whether the scene, subject, lighting and composition fit the brief. Delivery approval asks whether the exported file fits its actual use. This lets you revise a rejected composition cheaply without confusing a low-resolution preview with a finished asset.

Calculate cost per accepted image

Your production cost is the cost of all billed attempts divided by accepted assets. The unit is an accepted deliverable, rather than an attractive generation in a gallery.

Consider a synthetic campaign that needs 20 finished images. The team explores five concepts per finished image, giving 100 billed concept attempts. If all attempts use 4K, generation spend is 100 × $0.607 = $60.70. If all attempts use 1K, the arithmetic is 100 × $0.048 = $4.80, although those images still need delivery checks.

A staged budget can reserve 1K for those 100 concepts and 4K for 20 separately generated final candidates. Its spend is $4.80 + 20 × $0.607 = $16.94, or $0.847 per accepted image if all 20 final candidates are accepted. This is a planning scenario. It assumes a separate final generation for each approved direction and does not assert that regenerating a prompt preserves the exact concept.

If the team needs two final attempts per accepted asset, the high-resolution count becomes 40. The total is $4.80 + 40 × $0.607 = $29.08, or $1.454 per accepted image. The difference comes from final-stage rework. Track that rework explicitly rather than describing a single 4K generation as the entire production cost.

Use this small calculator with your own quantities:

from decimal import Decimal

rates = {"1k": Decimal("0.048"), "4k": Decimal("0.607")}
concept_attempts = 100
final_attempts = 40
accepted_images = 20
cost = concept_attempts * rates["1k"] + final_attempts * rates["4k"]
print(cost)                       # 29.080
print(cost / accepted_images)     # 1.454

This calculation was executed locally. It makes no API request. Replace the rates after rechecking the provider's current table; replace the attempt counts with your production records.

Decide when a higher tier pays for itself

Higher resolution is worth buying when it prevents a real delivery failure or saves enough downstream labor. It is less useful when the rejected asset has the wrong product, composition or copy.

The rate difference between a 4K and a 2K generation is $0.607 − $0.100 = $0.507. For an illustrative editing cost of $60 per hour, that premium equals about 30.42 seconds of labor. The calculation is $0.507 ÷ $60 × 3,600. This is a labor break-even assumption, not a measured time saving. If the larger source avoids more than that amount of useful editing time on an accepted asset, the premium may be reasonable.

Avoid applying the labor comparison to every exploratory attempt. A high-resolution image rejected for the wrong composition has not saved finishing labor. Compare the premium only where the source resolution changes an actual finishing decision.

Run a small paired check using the same brief, references, aspect ratio and acceptance criteria. Keep the requested tier as the deliberate difference. Record the exported dimensions, detail defects, crop losses, editing minutes and accepted result. If the outputs differ compositionally, describe that difference rather than attributing every outcome to resolution.

Make the generation record useful

The FLUX 3 Image documentation names the endpoint POST https://api.bfl.ai/v1/flux-3-image and accepts a resolution value such as 1k, 2k or 4k. It also documents asynchronous result polling and an expiring result download. Keep the provider task record and download the accepted output while it remains available.

A practical asset record includes brief version, requested tier, aspect ratio, references, provider task ID, billing status, delivered dimensions, reviewer and acceptance reason. Keep failure categories short: composition, identity, text, detail, crop and technical delivery. These fields explain whether your next action should be a prompt revision, a higher-resolution request or a layout change.

Review output billing separately from job submission. A submitted request is not an accepted campaign image. Retain the actual billed count and its corresponding outcomes so a monthly total can be reconciled. Downloading a file also does not prove that its content is approved for publication; the editor's acceptance record supplies that decision.

Build an image-budget workbench with Atoms

If multiple people approve images, put the decisions in a small shared application. Atoms can build a website or web app from a natural-language brief and let you iterate through a preview. A useful first version accepts user-entered generation records and rates. Connecting BFL later requires its own API credentials and integration work.

Use this brief:

Build an image production budget workbench. Let an editor enter a brief ID,
provider, exact model, rate-card date, requested resolution tier, unit rate,
billed attempt count, accepted asset count and editing minutes. Store each
budget version and source URL. Compute generation spend as the sum of
billed count times the corresponding rate. Compute cost per accepted asset
only when accepted count is positive; otherwise show no accepted result.
Show concept and final attempts separately. Export the exact inputs and
calculations as CSV. Start with manual records; do not invent an API connector.

In the preview, enter the 100-concept, 40-final example and verify $29.08 total. Save a record, reload it and confirm that rates, counts and source date persist. Test that an editor cannot silently change a previously approved budget. If you add cloud persistence, use the Atoms Cloud guide to choose the backend path and verify record permissions before sharing the application.

Conclusion

Choose FLUX 3 Image resolution from the asset's delivery requirements, then calculate the cost of all attempts needed to reach acceptance. For exploratory work, a staged budget can be substantially cheaper, provided you account for separate final generations and their rework. Build an image-budget workbench in Atoms when the team needs a saved, reviewable record of that decision.