How does OpenAI bill a gpt-image generation, and what drives the cost?

## Flat price to token metering The older DALL-E endpoints had a price list: pick a model and a size, pay a fixed amount per image. Capacity planning was arithmetic on request counts. gpt-image changed the model to token metering, which aligns image generation with the rest of the platform's billing but breaks every dashboard that assumed one call equals one known price. Three token streams appear on an image call: 1. **Text input tokens** — your prompt. Usually small, but not free, and prompts assembled from long templates or user-supplied descriptions add up at volume. 2. **Image input tokens** — charged when you send images in, which happens on `/v1/images/edits`. Every reference image you attach is counted, so a multi-reference edit is materially more expensive than a plain generation. 3. **Image output tokens** — the dominant term. This is what the render costs, and it is determined by the requested `size` and `quality`. ## Size and quality are the cost dial The accepted `quality` values for gpt-image are `low`, `medium`, `high` and `auto`, and `size` covers a square, a portrait, a landscape preset and `auto`. Output token counts climb steeply as you move up the quality tiers and as the pixel area grows. The engineering consequence is that quality is a *budget decision made per call site*, not a global default: - A grid of exploration thumbnails a user will scroll past belongs at `low`. - An in-progress preview inside an editing loop belongs at `low` or `medium`. - The final asset a user exports, prints or publishes belongs at `high`. Teams that migrated by mapping the old `hd` tier to `high` everywhere often discovered the bill after the fact, because the expensive tier was now applied to drafts nobody kept. ## Read usage, do not count requests The response includes a `usage` object with input and output token counts for the call (with input broken down between text and image contributions). This is the number to persist. Concretely, a workable telemetry design records, per generation: tenant or user id, the prompt hash, `model`, `size`, `quality`, `n`, and the `usage` numbers, keyed to the stored asset. That gives you three things request counting cannot: accurate per-tenant chargeback, the ability to attribute a cost spike to a specific call site, and evidence for whether a quality downgrade actually saved money. ## Where the money leaks - **Silent re-renders.** Generation is non-deterministic, so there is no cache-by-prompt on the provider side. If your UI regenerates on every page load, navigation or retry, you pay every time. Persist the bytes and key the asset by the request parameters yourself. - **`n` greater than one.** Each image in the batch is billed; `n=4` is four renders, not a bulk discount. It is a good product choice for a chooser UI and a bad default. - **Abandoned work.** Users generate far more than they keep. Cost per *kept* asset, not cost per call, is the metric that reflects the product. - **Edit loops.** Each turn of an iterative edit re-uploads image inputs and produces a new output, so a ten-step refinement costs roughly ten generations plus the input images each time. - **Streaming partials.** Requesting intermediate preview frames adds billed output; it buys perceived latency, and you should decide whether that trade is worth it per surface. ## Rate limits are a separate constraint Cost and throughput are different ceilings. Image endpoints have their own request-rate limits, and an image render takes seconds, not milliseconds, so a burst of user-triggered generations queues. The architectural answer is usually a job queue with per-user concurrency caps: it protects the rate limit, gives you a natural place to enforce a spend budget, and lets the UI show progress rather than block a request thread. ## Guardrails worth building For any multi-tenant product, a per-tenant token budget checked before the call, with a hard stop and a soft warning, is cheap to build and prevents the runaway case. Pair it with a default quality set by surface rather than by config, and an alert on tokens-per-kept-asset rather than tokens-per-day — the ratio moves first when a UI change starts burning renders. ## What interviewers are checking The weak answer is "you pay per image". The strong answer names the token model, identifies size and quality as the levers, points at the `usage` object as the source of truth, and then talks about the non-obvious leaks: re-renders, abandoned generations and edit loops. That progression shows someone who has operated an image feature rather than merely called the endpoint.