feat(api): add GPT Image 2.5 models and image options - #3824
Conversation
Castiron-Internal-PR: openai/openai-python-internal#79 Castiron-Source-SHA: a536ddf31b2137752c45947b05ec4ad152d995ea Castiron-Public-Base-SHA: f1cd7f0
Castiron custom code✅ No new custom-code files detected. 36 mixed files remain; 0 existing customizations changed; 5 generated baselines changed. Compared
31 existing customizations unchanged
A changed generated baseline means this report cannot reliably identify which handwritten lines changed. Inspect the custom-code diffDownload the exact patch produced by this run (requires repository access): gh run download 34287760208 --repo openai/openai-python \
--name castiron-custom-code-34287760208-1 --dir /tmp/castiron-custom-code-34287760208-1
git apply --stat /tmp/castiron-custom-code-34287760208-1/custom-code.patch
cat /tmp/castiron-custom-code-34287760208-1/custom-code.patchOr reproduce it from an SDK checkout containing the vendored reporter: git fetch --no-tags origin f1cd7f020210ec3fc71699fc46d90320ddbb411c 93058483e1105703cc7e43bfc8b072bc4b987928
python3 scripts/castiron/custom_code_report.py report \
--base f1cd7f020210ec3fc71699fc46d90320ddbb411c \
--head 93058483e1105703cc7e43bfc8b072bc4b987928 --fetch --require-head-hash --public \
--out /tmp/castiron-custom-code-93058483e110
cat /tmp/castiron-custom-code-93058483e110/custom-code.patchThis is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 93058483e1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if self._reconnect_attempt: | ||
| # Account for raw application progress without changing frame delivery. | ||
| try: | ||
| event_data: object = json.loads(message) |
There was a problem hiding this comment.
When recv_bytes() receives the first non-error event after a reconnect, this now materializes the complete JSON object solely to update retry accounting; callers using the raw API to process very large image, audio, or Responses events therefore incur an unexpected full parse and allocation before receiving the bytes, and .recv() parses that same event a second time. This pattern is duplicated across the synchronous and asynchronous Realtime, Responses, and Beta Responses connections and can cause severe latency or memory exhaustion for payloads that were previously passed through unchanged; track application progress without fully materializing the raw payload.
AGENTS.md reference: AGENTS.md:L114-L121
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
The raw-read change preserves retry-budget accounting after a reconnect. The extra JSON decode runs while the retry budget is consumed; a healthy non-error event resets it. Raw bytes are preserved, but parsing/allocation overhead is real and typed recv() can parse the same event again. I'd accept that tradeoff here and handle optimization separately rather than undo the retry fix. I haven't benchmarked large-frame overhead.
There was a problem hiding this comment.
@jbeckwith-oai could you take another look at the response above? Are you comfortable with retaining the retry fix here and addressing the parsing overhead separately, or is there something else you need before re-reviewing?
| - items: | ||
| $ref: '#/components/schemas/InputItem' | ||
| type: array | ||
| maxItems: 131072 |
There was a problem hiding this comment.
This publishes a new 131,072-item rejection limit for token-count requests, with the same limit added to the regular and beta compact/token-count schemas. Mock validators and clients generated from this OpenAPI contract can reject larger request bodies that previously had no item-count ceiling, despite the repository requiring an explicit owner-approved API contract and transport review for any new payload limit; remove it unless that contract has been established.
AGENTS.md reference: AGENTS.md:L114-L121
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
maxItems: 131072 is expected and should remain aligned with the intended Responses API contract. This PR exposes it in the bundled specification; it does not add SDK-side runtime validation. I acknowledge that schema validators now see a constraint the previous bundle omitted. I'd retain it here rather than remove the contract's limit. I am not claiming new boundary-test coverage.
There was a problem hiding this comment.
@jbeckwith-oai could you take another look at the response above? Are you comfortable with retaining the expected 131,072-item API constraint, or is there something else you need before re-reviewing?
| The paired `live.call.incoming` event derives its `session_id` by replacing the | ||
| `rtc_` prefix with `live_`. Use the ID returned by the event with the |
There was a problem hiding this comment.
The documented prefix replacement is inconsistent with the paired examples in the generated API reference: replacing rtc_ in rtc_479a... with live_ produces live_479a..., while the Live event now shows live_u0_479a.... Consumers following this rule to correlate the two webhook events or derive an ID will obtain a value that cannot match the Live ID; document the actual transformation, including u0_ if it is invariant, or avoid claiming the ID can be derived.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Agreed that the prefix-conversion guidance is inconsistent. Callers should use the ID supplied by the corresponding webhook unchanged. This is tracked for a documentation correction; I'd like to address the wording in a follow-up. It is not fixed in this head.
There was a problem hiding this comment.
@jbeckwith-oai could you take another look at the response above? Are you comfortable with taking the documented wording correction as a follow-up, or is there something else you need before re-reviewing?
jbeckwith-oai
left a comment
jbeckwith-oai
left a comment
There was a problem hiding this comment.
Thanks — the GPT Image 2.5 model aliases, quality values, custom dimensions, and nullable image-call metadata are largely generated as expected, and the current CI is green. I found three blocking regressions on this exact head:
-
The new Live/Realtime webhook guidance gives an invalid deterministic mapping. The example pairs
rtc_479a…withlive_u0_479a…, but the prose says to replace onlyrtc_withlive_, which produceslive_479a…. Please correct the authoritative spec and regenerate, or avoid telling callers to derive this ID and direct them to the event-provided session ID. -
The bundled transformed spec adds
maxItems: 131072to four existing Responses input arrays (stable/beta create, compact, and token-count paths). That is unrelated to this image update and newly makes schema-validating consumers reject shapes that were previously accepted. Please remove this unrelated constraint from this PR unless it is an approved API contract change with the appropriate boundary coverage. -
The reconnect bookkeeping now calls
json.loads(message)inside each rawrecv_bytes()path and the ordinaryrecv()path then parses the same payload again. After a reconnect this makes large image/audio/Responses frames incur a full extra decode/allocation even for callers explicitly using the raw-byte API. Please reset the retry budget without decoding the full raw frame twice, and add coverage for the raw receive path.
Once these are addressed and regenerated, I am happy to re-review.
|
Thanks Justin — I'd like to propose the following disposition:
CI is complete and green on the unchanged head. @jbeckwith-oai, could you re-review and confirm whether you're comfortable with these follow-ups? The deferred issues are acknowledged, not fixed by this PR. |
Automated Release PR --- ## [3.10.0](openai/openai-python@v3.9.0...v3.10.0) (2026-09-08) ### Features * **api:** add GPT Image 2.5 models and image options ([openai#3824](openai#3824)) ([5b39c45](openai@5b39c45)) * **api:** add service-account API key expiration fields ([openai#3802](openai#3802)) ([f1cd7f0](openai@f1cd7f0)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: openai-sdks[bot] <284451331+openai-sdks[bot]@users.noreply.github.com>
4 participants
Adds GPT Image 2.5 Sunburst/Flare aliases and September 8 snapshots,
xhigh/maxquality, and custom image dimensions.qualityandsizeon Responses image calls, includingquality: "auto".