Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

For OpenAI gpt-image family models (gpt-image-1, gpt-image-1-mini, gpt-image-1.5, gpt-image-2, ...), prefer token-based cost calculation using the model's input_cost_per_token / input_cost_per_image_token / output_cost_per_image_token and the usage returned by the API, instead of (or as a fallback to) the (quality, size)-aliased per-image lookup in default_image_cost_calculator.

Concretely:

• When the cost map entry resolved for a gpt-image call has token-based cost keys, compute cost as prompt_tokens × input_cost_per_token + image_input_tokens × input_cost_per_image_token + image_output_tokens × output_cost_per_image_token (mirroring openai_gpt_image_cost_calculator / generic_cost_per_token).

Motivation, pitch

OpenAI's image API responses already carry the right data for token-based costing (verified against a prod /v1/images/generations call to gpt-image-2):

  "usage": {
    "prompt_tokens_details":     {"text_tokens": 22,  "image_tokens": 0},
    "completion_tokens_details": {"text_tokens": 0,   "image_tokens": 1372}
  }

image_tokens scales with the rendered resolution, so token-based pricing naturally handles any size OpenAI accepts.

The current path in litellm/cost_calculator.py::default_image_cost_calculator resolves cost via a 7-step model-name lookup chain:

  {quality}/{provider}/{size}/{model}
  {provider}/{size}/{model}
  high/{provider}/{size}/{model_no_prov}
  {quality}/{size}/{model_no_prov}     ← e.g. high/1024-x-1024/gpt-image-1
  {quality}/{size}/{model_no_prov}     ← e.g. high/1024-x-1024/gpt-image-1
  {size}/{model_no_prov}
  {quality}/{size}/{model_no_prov}     ← e.g. high/1024-x-1024/gpt-image-1
  {size}/{model_no_prov}
  {model}
  {model_no_prov}

  {quality}/{size}/{model_no_prov}     ← e.g. high/1024-x-1024/gpt-image-1
  {size}/{model_no_prov}
  {quality}/{size}/{model_no_prov}     ← e.g. high/1024-x-1024/gpt-image-1
  {size}/{model_no_prov}
  {model}
  {model_no_prov}

For models registered in model_prices_and_context_window.json with the standard 9 (low|medium|high) × (1024-x-1024 | 1024-x-1536 | 1536-x-1024) entries (e.g. gpt-image-1, gpt-image-1.5), the standard sizes hit and per-image cost is recorded correctly.

But for any other resolution this lookup returns no match, the function raises Exception("Model not found in cost map"), the cost is swallowed downstream, and the request lands in LiteLLM_SpendLogs with spend = 0.

This is particularly visible with gpt-image-2. Per the OpenAI pricing page:

"gpt-image-2 supports thousands of valid resolutions; the table below lists the same sizes used for previous GPT Image models for comparison." ref : https://developers.openai.com/api/docs/guides/image-generation#calculating-costs

OpenAI publishes the per-image table only for the 9 reference cells; the actual billing model is token-based.

So once a caller picks any non-standard size (e.g. 768x768, 2048x2048, or any of the "thousands of valid resolutions"), the size-aliased path can never match and cost tracking silently drops to 0 — even though the response carries everything needed to compute the correct token-based cost.

Real example from our LiteLLM_SpendLogs (after registering only gpt-image-2 token-cost entry, no size aliases):

  model              | call_type         | spend   | prompt_tokens | completion_tokens
  openai/gpt-image-1 | aimage_generation | 0.24967 | 22            | 1372
  openai/gpt-image-2 | aimage_generation | 0       | 22            | 1372     ← same usage shape, lost cost
  openai/gpt-image-2 | aimage_edit       | 0       | 1962          | 5488

gpt-image-1 works only because BerriAI/litellm's cost map happens to include the 9 size-aliased entries; gpt-image-2 (and any non-standard size on gpt-image-1) does not. Adding the 9 cells for gpt-image-2 would close the standard-size case but still leaves every non-standard resolution at spend 0.

A token-based calculation path would make this provider-correct and resolution-independent.

Proposed direction

1. In default_image_cost_calculator (or route_image_generation_cost_calculator's OpenAI branch), if the resolved cost entry has token-based keys (input_cost_per_token / input_cost_per_image_token / output_cost_per_image_token), compute via generic_cost_per_token using the response's usage block — same logic that already exists in openai_gpt_image_cost_calculator.
2. Keep the existing per-image lookup as a fast path / explicit override when a (quality, size) entry matches, but no longer treat its absence as a hard failure — fall through to (1).
3. As a side benefit this would simplify maintenance: instead of registering an O(qualities × sizes) cross-product per new gpt-image model, a single token-cost entry would suffice.

What part of LiteLLM is this about?

Proxy

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

Twitter / LinkedIn details

https://www.linkedin.com/in/세환-김-a31543202/