AI image API cost per approved image: A Budget Guide

Your catalog service needs 1,000 usable product images, but its generation counter reaches 1,400 before review finishes. AI image API cost per approved image explains the difference between a model's listed output price and the amount your application spends delivering accepted assets. Budgeting against successful HTTP responses misses rejected compositions, additional revisions, and images generated at the wrong resolution.

This cost breakdown uses GenRelay image prices supplied for October 31, 2026. Workload sizes and approval rates below are illustrative planning assumptions, not measured model benchmarks. The Python examples run locally without credentials or generation requests, so you can inspect the accounting before connecting it to your application.

What does cost per approved image measure?

Cost per approved image is the generation spend attributable to a workload divided by the number of images accepted from that workload. An approved image is an output that passes your product's specified review criteria, not merely a file that downloaded successfully.

For a product catalog, those criteria might include correct packaging, readable labeling, acceptable composition, and a match to the actual item. For an editorial illustration, composition and licensing review may matter more than exact product identity. Define acceptance before comparing models; changing the rubric halfway through a test changes what the denominator means.

Keep these metrics separate:

• Listed unit price: the quoted generation charge for a model and resolution.
• Observed generation cost: the actual recorded charge across relevant attempts.
• Approval rate: accepted outputs divided by reviewed outputs in the selected cohort.
• Cost per approved image: recorded generation spend divided by accepted outputs.
• Fully loaded delivery cost: generation, review, storage, and other attributable expenses divided by delivered assets.

A cohort is a group of records selected using a shared boundary, such as one campaign and its revisions. Count an image once even if it appears on several product pages. If no images are approved, report the metric as undefined rather than displaying zero dollars.

Which image prices belong in the estimate?

Use the model and resolution actually selected for each generation, rather than applying one average price to every request. The supplied GenRelay prices are:

Model	Resolution tier	Listed price per image
Nano Banana Pro	1K	$0.030
Nano Banana Pro	2K	$0.030
Nano Banana Pro	4K	$0.042
Nano Banana 2	1K	$0.020
Nano Banana 2	4K	$0.036
GPT-image-2	Supplied per-picture rate	$0.014

The GPT-image-2 rate here does not establish a specific resolution tier or parameter support. Likewise, a missing Nano Banana 2 tier is not an invitation to interpolate its price. Verify current request options and account pricing before implementing the network adapter that submits generations.

Review Nano Banana model options and the GPT-image-2 model page when mapping a workload to your integration. A price table does not establish comparative visual quality, latency, or instruction-following performance. Those require a controlled evaluation using your own inputs.

For a single pass of 1,000 outputs, the listed generation totals are $14 for GPT-image-2, $20 for Nano Banana 2 at 1K, $30 for Nano Banana Pro at 1K or 2K, $36 for Nano Banana 2 at 4K, and $42 for Nano Banana Pro at 4K. These are output totals, not promises of 1,000 approved deliverables.

How does rejection change an image generation budget?

Rejection increases the expected number of outputs required to reach an acceptance target. Under a simplified model with a stable approval probability, expected generation spend equals target approved images multiplied by unit price and divided by approval rate.

For example, assume Nano Banana 2 at 1K has a 75% approval rate on your workload. Reaching 1,000 accepted images then requires approximately 1,333.33 outputs in expectation, corresponding to $26.67 in expected generation spend. A procurement estimate should round output counts upward, while recognizing that rounding does not provide a statistical confidence bound.

At a hypothetical 50% approval rate, the same target has an expected generation cost of $40. The model price has not changed; the acceptance assumptions have. Do not publish those percentages as characteristics of Nano Banana 2. They are scenario inputs for this calculation.

Save this standalone example as image_budget.py and run it with Python 3:

from decimal import Decimal, ROUND_CEILING


def estimate(target, unit_price, approval_rate):
    price = Decimal(unit_price)
    rate = Decimal(approval_rate)
    if target < 1 or price < 0 or not Decimal('0') < rate <= 1:
        raise ValueError('Invalid target, price, or approval rate')
    outputs = (Decimal(target) / rate).to_integral_value(
        rounding=ROUND_CEILING
    )
    return int(outputs), outputs * price


outputs, cost = estimate(1000, '0.020', '0.75')
assert outputs == 1334
assert cost == Decimal('26.680')
print({'planned_outputs': outputs, 'generation_budget_usd': str(cost)})

Decimal represents base-ten quantities without binary floating-point rounding artifacts. This matters when adding many small charges. Keep sufficient precision in your ledger and round for display according to your accounting rules.

The estimate assumes the approval rate stays stable and further attempts remain useful. In practice, a repeated failure may indicate an unsuitable reference, incompatible requirement, or prompt problem. Put a revision ceiling on each asset and escalate repeated failures rather than treating unlimited retries as a budget strategy.

How should revisions and mixed resolutions be counted?

Count every charged attempt in the relevant asset history, including drafts that informed a later accepted version. A revision is a new generation requested to improve or change an earlier output; it is not free simply because your application labels it as part of the same task.

Consider 1,000 Nano Banana 2 drafts at 1K followed by 250 Nano Banana Pro generations at 4K. The generation spend is $20 plus $10.50, or $30.50. If the final reviewed set contains 900 distinct accepted assets, generation cost per approved asset is approximately $0.03389. If the 4K outputs replace earlier drafts, do not count both versions as separate delivered assets.

This example does not assume that a 4K generation is a deterministic enlargement of the original. Treat generation and image resizing as different operations, and verify which editing or reference options your selected model supports. A revised output may require another content review even when its source image was previously accepted.

Use a lineage record connecting each output to its asset identifier, parent attempt, model, selected resolution, and review outcome. Lineage is the recorded relationship between successive artifacts. It lets finance attribute spend to an asset while reviewers identify the version actually approved.

How can Python calculate realized costs from a review ledger?

Calculate realized cost from recorded charges and distinct accepted asset identifiers, not from a fresh estimate based on the latest price list. Historical attempts may have used a different tier or rate.

The following standalone fixture illustrates that calculation. The charged_usd values are sample records, not a claim about an API response schema. Adapt your billing export into this internal representation after verifying its documented fields.

from decimal import Decimal

rows = [
    {'asset': 'a', 'charged_usd': '0.020', 'accepted': False},
    {'asset': 'a', 'charged_usd': '0.030', 'accepted': True},
    {'asset': 'b', 'charged_usd': '0.014', 'accepted': True},
    {'asset': 'c', 'charged_usd': '0.036', 'accepted': False},
]


def summarize(records):
    spend = sum((Decimal(r['charged_usd']) for r in records), Decimal(0))
    accepted = {r['asset'] for r in records if r['accepted']}
    return {
        'spend': spend,
        'approved_assets': len(accepted),
        'cost_per_approved': spend / len(accepted) if accepted else None,
    }


report = summarize(rows)
assert report['spend'] == Decimal('0.100')
assert report['cost_per_approved'] == Decimal('0.050')
assert summarize([])['cost_per_approved'] is None
print(report)

In production, resolve review history to the current approved version before creating these rows. Revoked approvals should not remain in the accepted set. Include unresolved charges explicitly in reconciliation reports instead of silently assuming they cost nothing.

Which engineering controls reduce avoidable spend?

Preventing unintended duplicate submissions and stopping unproductive revisions can reduce waste without changing the selected model. Neither control establishes a particular savings percentage; measure its impact against your own ledger.

First, give each intended user operation a durable application identifier. Follow the image request deduplication guide to distinguish an intentional revision from an accidental repeated submission. A network timeout does not establish that a generation was rejected or unbilled.

Second, validate dimensions, source-image permissions, and required inputs before submitting. Third, separate draft evaluation from final-resolution requests, while budgeting any additional final-stage review. Fourth, cap both attempts per asset and aggregate campaign spend. Finally, reconcile estimated charges against actual billing records before presenting final campaign margins.

Use an explicit release gate for customer-facing imagery. Generated labels, product proportions, and colors should be checked against authoritative references. A low generation cost is not a reason to publish an inaccurate representation of a product.

What do developers frequently ask about image approval costs?

The common questions concern interpretation of the denominator and the distinction between planning and observed billing.

Is the lowest listed image price always the lowest delivery cost?

No. Delivery cost also depends on acceptance, revision volume, review effort, and required output specifications. Compare models on the same representative input set with the same acceptance rubric, then calculate actual spend per accepted asset.

Should failed or timed-out requests be counted?

Count their recorded charges when applicable, and track uncertain billing separately until reconciled. Do not infer refund behavior or billing status from an HTTP timeout. This article does not establish a GenRelay refund policy for failed jobs.

Can an approval-rate estimate enforce a hard spending limit?

No. An expected-value calculation forecasts average behavior under its assumptions. A hard spending limit needs application-side admission controls and a ledger that accounts for in-flight requests before admitting further work.

Should human review be included in this metric?

Keep generation cost per approved image as a distinct metric, then add review and other attributable expenses for a fully loaded figure. Reporting both makes model economics comparable while preserving visibility into the actual cost of delivery.