Codex API image_generation silently ignores size/quality and returns gpt-image-2-codex auto output

Open 💬 7 comments Opened Jun 17, 2026 by jzhao20230918

What issue are you seeing?

Codex API image_generation silently ignores explicit size and quality parameters.

A request for gpt-image-2, quality=high, and size=2160x3040 is accepted through the Codex API / OAuth-backed image generation path, but the returned tool metadata is changed to:

  • model=gpt-image-2-codex
  • quality=auto
  • size=auto

The final PNG is not 2160x3040.

This makes the Codex API image path unreliable for workflows that require deterministic output dimensions.

Expected behavior

Codex API should either honor the requested size and quality, or return a clear error if deterministic size / quality is not supported by the Codex API image generation path.

It should not silently downgrade the request while still returning success.

Requested parameters

{
  "type": "image_generation",
  "model": "gpt-image-2",
  "quality": "high",
  "size": "2160x3040",
  "output_format": "png"
}

Actual returned tool metadata

{
  "type": "image_generation",
  "model": "gpt-image-2-codex",
  "quality": "auto",
  "size": "auto",
  "output_format": "png"
}

Observed PNG dimensions

1024x1536
1054x1492
1058x1487
1254x1254
1693x929

Clarification

This issue is not about the native OpenAI Images API.

It is specifically about the Codex API / OAuth-backed image_generation path silently converting an explicit gpt-image-2 high/custom-size request into gpt-image-2-codex with quality=auto and size=auto.

What steps can reproduce the bug?

Send a Codex API / OAuth-backed image_generation request with explicit gpt-image-2, quality=high, and size=2160x3040.

Example request shape:

{
  "model": "gpt-5.5",
  "instructions": "Generate the requested image.",
  "input": [
    {
      "role": "user",
      "content": "Create a professional vertical research infographic. The output must be exactly 2160x3040 PNG."
    }
  ],
  "tools": [
    {
      "type": "image_generation",
      "model": "gpt-image-2",
      "quality": "high",
      "size": "2160x3040",
      "output_format": "png"
    }
  ],
  "tool_choice": {
    "type": "image_generation"
  },
  "store": false
}

Then inspect the returned response.created / response.completed tool metadata and the actual PNG dimensions.

Expected:

model=gpt-image-2
quality=high
size=2160x3040
PNG dimensions=2160x3040

Actual:

model=gpt-image-2-codex
quality=auto
size=auto
PNG dimensions are smaller than 2160x3040

What is the expected behavior?

Codex API should either honor the requested size and quality, or return a clear error if deterministic size / quality is not supported by the Codex API image generation path.

For a request with:

{
  "type": "image_generation",
  "model": "gpt-image-2",
  "quality": "high",
  "size": "2160x3040",
  "output_format": "png"
}

The expected output should preserve the requested parameters:

model=gpt-image-2
quality=high
size=2160x3040
PNG dimensions=2160x3040

If Codex API cannot support this, it should fail explicitly with a capability or validation error.

It should not silently convert the request to gpt-image-2-codex, quality=auto, size=auto, and return a smaller PNG while reporting success.

Additional information

_No response_

View original on GitHub ↗

7 Comments

jzhao20230918 · 2 months ago

Additional Timeline / Regression Window

This appears to be a regression rather than a long-standing unsupported behavior.

| Date / Time UTC | Observation |
|---|---|
| 2026-06-15 UTC | The same image generation workflow was still producing valid 2160x3040 PNG outputs that passed strict dimension validation. |
| 2026-06-16 UTC | The same workflow started failing dimension validation. Requests still explicitly asked for gpt-image-2, quality=high, size=2160x3040, and output_format=png, but the returned PNGs were smaller. |
| 2026-06-17 UTC | Repeated smoke tests continued to reproduce the downgrade through the Codex/OAuth-backed image path. |

jzhao20230918 · 1 month ago

Hi Codex team, thanks for looking into this.

I did a quick re-check of the latest public state and wanted to share a concise update:

  • This issue is still open and labeled bug, app-server, and imagen.
  • OpenAI image generation docs still document gpt-image-2 as supporting configurable size / quality.
  • The requested 2160x3040 size appears to be within the documented gpt-image-2 constraints.
  • The current Codex built-in image_generation tool spec still appears to expose only output_format, without size / quality.
  • Recent image-generation related Codex PRs I found (#28656, #29909) do not appear to address this silent gpt-image-2-codex / auto / auto downgrade.

Could you please clarify whether deterministic size / quality is intended to be supported on the Codex/OAuth-backed gpt-image-2-codex path?

If it is not supported on that path, a clear capability or validation error would be much safer than completing successfully with smaller images.

The main production blocker for us is the silent downgrade behind an HTTP 200 / completed response. This makes it hard to distinguish “unsupported capability” from “successful generation” programmatically.

Thanks again.

audaki · 1 month ago

This definitely doesn’t look intended. In it’s current state it’s hard to create small icons / pixel art, since I can’t properly control the downscale ratio. And directly generating a .webp also doesn’t work (anymore?)

<img width="1172" height="505" alt="Image" src="https://github.com/user-attachments/assets/b50f6cfa-9529-438f-95ff-b876273ef43a" />

luckyabsoluter · 1 month ago

also quality low is overridden to auto, lol.
Should I overload OpenAI server?

ArchSenex · 1 month ago

This was introduced when they rolled out the generations endpoints, I noticed it almost immediately, and they broke it both on responses and generations, neither one honors the size. It's also moderated much higher than API or even chatgpt endpoint.

jzhao20230918 · 1 month ago

Hi Codex team,

I ran an additional controlled A/B test to determine whether the downgrade was caused by the Responses image tool bridge or by the Codex image backend itself.

Both tests used the same active ChatGPT Pro OAuth account, prompt, and requested parameters:

{
  "model": "gpt-image-2",
  "quality": "high",
  "size": "2160x3040",
  "background": "opaque",
  "output_format": "png"
}

Test A: Responses image-generation tool

  • HTTP status: 200
  • Returned metadata: gpt-image-2-codex / medium / 1024x1536
  • Actual PNG dimensions: 1024x1536
  • Elapsed time: 41.5s

Test B: Dedicated Codex Images endpoint

Endpoint:

POST https://chatgpt.com/backend-api/codex/images/generations
  • HTTP status: 200
  • Returned metadata: medium / 1024x1536
  • Actual PNG dimensions: 1024x1536
  • Elapsed time: 55.8s

The actual dimensions were verified directly from the PNG IHDR bytes rather than inferred from response metadata.

This suggests that the issue is not limited to the Responses tool bridge. The dedicated Codex Images endpoint also accepted the explicit high / 2160x3040 request but returned a medium / 1024x1536 image.

Could you please clarify whether deterministic size and quality are intended to be supported for the Codex OAuth image-generation path?

If these controls are not supported, returning an explicit capability error would be much safer than silently completing with a lower-resolution image.

Thank you for looking into this.

luckyabsoluter · 1 month ago