Skip to content

docs(image): document gpt-image-2 / gpt-image-2-edit quality parameter#263

Open
Dervlex wants to merge 3 commits into
mainfrom
docs/gpt-image-2-quality-parameter
Open

docs(image): document gpt-image-2 / gpt-image-2-edit quality parameter#263
Dervlex wants to merge 3 commits into
mainfrom
docs/gpt-image-2-quality-parameter

Conversation

@Dervlex
Copy link
Copy Markdown
Contributor

@Dervlex Dervlex commented May 21, 2026

The quality parameter (low | medium | high, default high) is now honored end-to-end for gpt-image-2 and gpt-image-2-edit by web, public API, and SDK clients — no opt-in header required. Mobile clients remain on the legacy fixed price schedule until they ship their own quality UI.

Adds:

  • Quality-tier explanation + example to /image/generate, /image/edit, and /image/multi-edit endpoint docs.
  • model_spec.pricing.quality matrix example to /models endpoint doc.
  • Quality-tier pricing tables (1K/2K/4K × low/medium/high) to the pricing overview, with prices computed from the live FAL base rates plus the standard 1.15× markup.
  • Note in the image-models landing page pointing to the matrix.
  • quality property on GenerateImageRequest, EditImageRequest, MultiEditImageRequest, and MultiEditImageMultipartRequest in swagger.yaml. (The OpenAI-compat /v1/image/generations schema keeps its passthrough-only quality description — that endpoint still ignores the field for parity with OpenAI.)

Replaces the earlier draft branch (docs/gpt-image-2-dynamic-pricing) which described an unimplemented token-based pricing model. This branch matches what production actually exposes.

The `quality` parameter (`low | medium | high`, default `high`) is now
honored end-to-end for `gpt-image-2` and `gpt-image-2-edit` by web, public
API, and SDK clients — no opt-in header required. Mobile clients remain on
the legacy fixed price schedule until they ship their own quality UI.

Adds:
- Quality-tier explanation + example to /image/generate, /image/edit, and
  /image/multi-edit endpoint docs.
- `model_spec.pricing.quality` matrix example to /models endpoint doc.
- Quality-tier pricing tables (1K/2K/4K × low/medium/high) to the pricing
  overview, with prices computed from the live FAL base rates plus the
  standard 1.15× markup.
- Note in the image-models landing page pointing to the matrix.
- `quality` property on `GenerateImageRequest`, `EditImageRequest`,
  `MultiEditImageRequest`, and `MultiEditImageMultipartRequest` in
  swagger.yaml. (The OpenAI-compat `/v1/image/generations` schema keeps its
  passthrough-only `quality` description — that endpoint still ignores the
  field for parity with OpenAI.)

Replaces the earlier draft branch (`docs/gpt-image-2-dynamic-pricing`)
which described an unimplemented token-based pricing model. This branch
matches what production actually exposes.
@mintlify
Copy link
Copy Markdown
Contributor

mintlify Bot commented May 21, 2026

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
veniceai 🟢 Ready View Preview May 21, 2026, 10:26 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

…2K" footnote

API docs are about what the API does, not which clients call it. The mobile
reference also carried a quantitatively wrong claim — legacy fixed pricing
is ~$0.01 above dynamic-`high` for `gpt-image-2` at *all three* resolutions
(not just 1K/2K) and *identical* for `gpt-image-2-edit` at every resolution.
Re-frames the four Info blocks (generate, edit, multi-edit, pricing overview)
and the prose in the Models endpoint as API-and-SDK-centric, with no false
claim about a specific client's bill.
Resolves swagger.yaml conflict by accepting main's version. The outerface
auto-generated swagger (commit 05eb744 "Update swagger.yaml from outerface
deployment") already adds the `quality` parameter to the three request schemas
that need it (GenerateImageRequest, EditImageRequest, MultiEditImageRequest)
and additionally adds:

- `model_spec.pricing.quality` per-(resolution, quality) pricing matrix
- `model.quality.default` and `model.quality.options` per-model fields

My hand-written swagger additions in 60756d5 covered only the three request
schemas and would have been overwritten by the next outerface deployment
anyway (swagger.yaml is auto-generated upstream). Dropping them in favour of
the bot-generated version is the right call.

The .mdx documentation changes (the actual value of this PR) are unaffected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants