Image generation cost calculator: renders, keepers, and your own GPU

Image generation API cost is three bills wearing one word. One is a flat rate per image. Another is a rate per megapixel that rounds up. The third is a rate per token, and you cannot divide it by hand. First-hand reads on this page are dated 28 October 2026. The cheap tier of the FLUX family bills 0.003 per image, and the pro tier bills 0.04. That is a factor of thirteen. The next multiplier is you. At a 25 percent acceptance rate you buy four renders per keeper, so a 0.003 draft tier really costs 0.012 per image you keep. Your own card is the last surprise. Local power is noise. But a 1,599 card needs over half a million images to pay back against the cheap tier. This page works all of it in static tables. Every input is named and dated. There is no widget and no JavaScript. You can check every number with a pencil.

All amounts are United States dollar amounts written as bare numerals. A rate prints here only when it was read first-hand from the named party's own page on the date shown. Cells this page could not read are dashed. A dash is data too.

Last verified: 2026-10-28

Three billing units, one bill

Most pricing mistakes in image generation start with the units. A per-image rate and a per-megapixel rate look like the same kind of number. They are not. They are different units. Decode the unit first. Then do arithmetic.

The round-up rule deserves one worked line because it moves real bills. fal's own model pages say images are billed "by rounding up to the nearest megapixel." A 0.9 megapixel image bills as 1 megapixel. A 1.6 megapixel image bills as 2. The trap sits just past the boundary. A 1024x1024 image is 1,048,576 pixels, which is 1.05 megapixels. Under proportional math that is 1.05 units. Under the round-up wording it is 2 units, and the image costs double. The same party's pricing page says higher resolutions are "priced proportionally." The two wordings disagree exactly at that boundary. Treat the boundary case as unknown until you measure one image. Keep reading rates in the unit they print.

Flat per-image billing has no boundary at all. On this platform a 1024x1024 and a 768x1344 bill the same, per the platform's published API contract as of 28 October 2026.

The rate ladder, read on one day

Every row below was read from the named party's own pricing surface on 28 October 2026. Nothing here comes from a summary site or a search snippet.

Sources, read first-hand: fal's schnell page, fal's 1.1 pro page, Replicate's pricing page, Together's pricing page, the publisher's own pricing page, OpenAI's pricing page.

Three observations fall out of the ladder. The pro class is stable. FLUX 1.1 pro sits at 0.04 at three of the four named hosts. The publisher launched it at 4 cents per image in its own October 2024 announcement. Cheap holds stable too, at 0.003. The publisher's own current default, FLUX 3 Image at 0.048 per 1K-resolution image, prices above both old tiers. Together's newest tier, FLUX.2 pro at 0.03, lands between them. New generations do not inherit the old prices in any fixed direction. The math on this page works for any rate you read, those included.

One generation note, stated plainly. This platform serves the FLUX.1 generation on its images lane, flux-1-schnell and flux-pro-1.1. Both rows were serving as of 28 October 2026. Schnell is built for speed. It generates in 1 to 4 steps by design, per its official model card. First bytes on the platform's schnell route landed in 3.1 to 4.2 seconds, measured 2026-09-24. The publisher claims the pro tier is six times faster than its predecessor. That claim appears on fal's page and in the announcement.

Keepers, not renders

Nobody ships every render. You generate candidates, keep some, and throw the rest away. The bill counts everything you generated. That is the single biggest gap between what a rate table says and what you pay.

renders per keeper  =  1 / acceptance rate
cost per keeper     =  per-image rate x renders per keeper

The 25 percent row is not a scare case. One calculator in the wild works this exact math and quotes it: at 25 percent acceptance, a 0.04 render costs 0.16 per shipped image. Community threads say the same thing in words: you usually need several attempts to get one you keep. Stock contributors report rejection rates that would make 25 percent look generous.

Now the tier trade, the one that surprises people. A cheap tier at bad acceptance loses to a good tier at high acceptance. The 0.04 tier at 75 percent acceptance costs 0.053 per keeper. The same tier at 35 percent costs 0.114, more than double. If a stronger model lifts your acceptance from 35 to 75 percent, it pays for itself twice over at the same sticker price. Price the keeper, never the render, and the tier decision makes itself.

One sleeper belongs next to this math: your review time. At 15 seconds per render and a 30 per hour reviewer, reviewing 100 renders costs 12.50 of labor. The renders themselves cost 4 at the 0.04 tier. The looking costs more than the making. Cheap drafts are cheap. Cheap drafts you have to look at twice are not.

The wallet tables

The platform's own rates render in the table below straight from the catalog at build time. This page never types them. Read the flux rows off that table, then work the scenarios.

The formula is one line:

monthly cost  =  images per day  x  30  x  per-image rate
monthly keepers cost  =  keepers per day  x  30  x  rate / acceptance

Scenario rows, worked. Third-party rows use the dated reads above. Platform rows stay symbolic: put the fence rate in R and multiply. The pencil check is the same either way, because the fence is on this page.

Read the last two rows together. Same volume, same sticker price. On a per-megapixel host the bill doubles the moment your output crosses 1 megapixel. It doubles again past 2. On a flat per-image row the bill never moves. Budget on a per-MP host in the tier you will really generate at. The 1 MP default in the rate table is not your bill.

Wallet sizing is the other half of the calculator. This platform bills a prepaid wallet per request. Load for the work you plan. Treat the balance as your blast radius. The meter stops a runaway loop. A month-end invoice does not. The images route bills per image returned. You can ask for up to 10 images per call. A generation that fails bills zero. A partial return bills what returned. Those rules come from the platform's published API contract, as of 28 October 2026.

Your own card: the crossover nobody works

Every "run it locally for free" page stops at the missing API bill. The honest version works the crossover: how many images until a card you own beats the hosted tier. At home the marginal cost is power, and power is one line:

power per image  =  kilowatts  x  price per kWh  x  seconds / 3600

The anchors are official. A 4090-class card draws 450 watts total, per NVIDIA's spec page. United States residential power averaged 18.2 cents per kilowatt-hour in the 2026 outlook. The source is the EIA Short-Term Energy Outlook, October 2026 edition. Your bill is the number that matters. 18.2 is the anchor.

Speed tiers, because seconds drive the power term. A rental host's own measured round, August 2026, clocks schnell at roughly 300 images an hour at 4 steps on a 4090-class card. That is about 12 seconds an image. Community reports from a basic home stack run 30 to 60 seconds on a 3090-class card. The tables sweep three round tiers, 10, 30, and 60 seconds, as labeled parameter rows.

Power is noise. Even the slow tier burns 0.14 cents per image, against a 0.003 hosted rate. The right column multiplies the printed per-image cells by 30,000, so the pencil runs cell to cell. The crossover is about the card itself:

crossover images  =  card cost G / (hosted rate R - power per image)
monthly volume    =  crossover images / 24  (a 24-month payback window)

The 1,599 is the 4090-class launch list price from October 2022. That is a hardware list price, not anyone's API rate. Put your own G in. The formula does not care what you paid.

Now the honest reading. This is the part every local-vs-API page leaves out. Against the cheap tier, the card takes over half a million images to pay back. That is not a budget. It is a career. Against the pro tier the arithmetic looks friendlier, about 40,000 images. But the pro weights are closed. You cannot run that model at home at any price. The models you can run locally are the open ones. Schnell is Apache 2.0, so commercial use is clear, per its model card. Dev is non-commercial. The publisher's klein models self-host only under a paid license. Its entry rung caps you at 10,000 images a month, per the publisher's pricing page. So the only clean comparison is local schnell against hosted schnell. That comparison says the same thing three ways. Local wins on control. Local wins on privacy. Local wins offline. On money, local wins past tens of thousands of images a month. Not before.

Renting sits in the middle. One rental host's own rate, read August 2026, puts a 4090-class card at 0.39 per hour. Packed at the 10 second tier, that yields 0.001 per image. That is under the hosted cheap tier. But the card generates at 360 images an hour or zero. The meter runs either way. A full month of that rental is 0.39 times 730, which is 284.70, whether you generate or not. Rental beats API only when the card stays packed. That is a scheduling project, not a line item. The audio lane's cost calculator works this same rented middle. Its power table covers more card classes.

One measured image beats any table

Every table on this page is a set of dated reads. Rates move. The meter is the fact, and checking it costs less than a coffee. Send one image to the route you are pricing, then read the wallet.

The platform's first call, from the published API contract:

curl -sS $IRONSTRATUM_BASE_URL/v1/images/generations \
  -H "Authorization: Bearer $IRONSTRATUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "flux-1-schnell",
    "prompt": "a warehouse robot arm stacking blue crates, clean product photo",
    "n": 1,
    "size": "1024x1024"
  }'

The response carries a usage block. It holds the image count and the cost of that call, per the platform's API contract. So the check is one field read, not a guess. Generated image URLs are temporary by design. Fetch and store what you keep. The request shape above is the documented set. It takes a model, a prompt, up to 10 images, a size, and the URL response format. Send the same one-image check to any host you are pricing. Use the size you will really generate at. You have then measured the one number every rate table hides. Your exact image costs a known amount, in your exact unit.

Three habits close the section. Read rates from the party's own page, dated. Never take a rate from a summary panel. Dash what you cannot read. Re-read the two rates that matter to you on the day a decision rides on them. In 2026 some hosts moved image rates by factors, not decimals.

Frequently asked questions

How much does one AI image cost?

Across the first-hand reads dated 28 October 2026: 0.003 per image at the FLUX cheap tier, 0.04 at the pro tier. Both are for about 1 megapixel. The publisher's own current generation, FLUX 3 Image, defaults to 0.048 at 1K resolution. Token-billed rows need the party's own calculator for a per-image figure, so this page dashes them. Your real price per keeper also depends on your acceptance rate. The keepers table works that.

Is per-image or per-megapixel billing cheaper?

Neither, at 1 megapixel. They diverge with size. A flat per-image rate stays fixed at any resolution. A per-megapixel rate steps up each time your output crosses a whole megapixel, because fal and Together round up. If you generate at 2K or 4K, price the megapixel tier you will actually use. If you generate at 1024x1024 or below, the boundary case in the unit table is the only thing to watch.

How many images until my own GPU is cheaper?

Against the 0.003 tier, a 1,599 card crosses over past half a million images, power included, over a 24-month payback. That is over 20,000 images a month. Against a 0.04 tier the crossover is about 40,000 images. But that model's weights are closed. It cannot run locally. The clean comparison is open schnell against hosted schnell. Hosted wins below roughly 24,000 images a month.

Does image size change the price?

On a flat per-image row, no. This platform bills the same per image at any size, per its published API contract. On per-megapixel hosts, yes. You pay for megapixels rounded up. An image just past a boundary can bill as a whole extra megapixel. The 1024x1024 case sits at 1.05 megapixels, right on that line. Check whose wording governs before you budget at a boundary size. Or measure one image.

What is cost per accepted image?

The rate divided by your acceptance rate. At 25 percent acceptance, four renders buy one keeper. A 0.003 tier then costs 0.012 per keeper. A 0.04 tier costs 0.16. Budget keepers, review time included, not renders. The review time can cost more than the renders at low acceptance rates.

The short version travels well. Decode the unit before you compare rates. Price keepers, not renders. Work the crossover before you buy a card. The open weights are the only ones you can run yourself at scale. The platform's live rates render on the pricing page and on the fence above. Both come from the same catalog the meter reads. The images lane lives on the images category page. The two flux rows carry their own model pages. Want your own numbers? Sign up, fund a small wallet, send one image, and read the cost field. Do that before you read anything else on this page as a promise.

Last verified: 2026-10-28