Skip to main content
All image APIs are synchronous — there is no task ID to poll, and if your client disconnects the result is lost while the request is still billed. Set a generous timeout for this model; see Image API Essentials & Best Practices.

Overview

gpt-image-2.5-all and gpt-image-2-all are APIYI’s GPT image generation reverse-engineered models (ChatGPT web line). The ChatGPT web app has moved to Images 2.5 as a whole, so gpt-image-2-all already produces 2.5 images; the new gpt-image-2.5-all name simply makes that upgrade explicit — both names share the same price and behavior and are interchangeable; new projects should use gpt-image-2.5-all. With extremely competitive pricing at $0.025/image per call (cut from $0.03 on 2026-10-10), it generates images in about 30–60 seconds and supports text-to-image / single-image editing / multi-image fusion / natural-language editing — with high text-rendering fidelity and native support for Chinese prompts.
🎨 Highlights: Reliable reverse-engineered channel with a flat $0.025/image rate. You can now specify target dimensions with size and still describe size, aspect ratio, and style in the prompt. An explicit size takes priority; omitting it or passing auto preserves native behavior. Uses the OpenAI Images API standard endpoints: /v1/images/generations (text-to-image) and /v1/images/edits (image editing).For 4K requirements, see the 4K model choices below.

Text-to-Image API

/v1/images/generations — generate images from text prompts.

Image Editing API

/v1/images/edits — multipart upload with edit/fusion instructions.

Let an AI Agent Do the Integration

Copy this prompt and paste it into Codex / Claude Code / Cursor

It first fetches the plain-text version of this page (append .md to any docs URL), then writes code in your project's own stack — timeout, base64 rendering, upload compression, and the parameters this model rejects are already baked into the requirements.

Integrate / troubleshoot gpt-image-2-all text-to-image and image editing in this project.

Read the docs before you touch code: fetch https://docs.apiyi.com/en/api-capabilities/gpt-image-2-all/overview.md for the plain-text version of this page. For finer parameter detail, append .md to …

  1. Timeout: raise the client timeout to 360 seconds. The image APIs are synchronous — there is no task ID, so if the client disconnects the result is lost …

6 requirements in total. Use the button below to copy the full prompt.

Core Features

Highly Competitive Pricing

Flat per-call pricing of $0.025/image, no resolution tiers, predictable costs

High Text Rendering

Stable rendering of Chinese/English text, signs, and poster text — ideal for infographics and marketing assets

Chinese Prompt Friendly

Native understanding of Chinese descriptions without translation

Multi-Image Fusion

Supports multiple reference images; prompts can reference them as “image1/image2/image3”

Faster Output

~30–60s generation — faster than both gpt-image-2-vip and the official-relay gpt-image-2

R2 CDN Accelerated

Pass response_format: "url" explicitly for R2 CDN links with low-latency global delivery

Natural-Language Editing

Edit via conversational descriptions, no masks required, supports multi-turn iteration

Standard Endpoint Support

Compatible with the OpenAI Images API standard endpoints /images/generations and /images/edits

Pricing

Billing notes:
  • Flat pricing; no tiers by resolution, quality, or prompt length
  • Failed requests are not charged (auth failures, parameter validation errors)
  • For N images, call the API N times in parallel
Model prices are aligned with the official ones and may change when the provider adjusts them; the table above is for reference only — the Model Pricing tab in the top navigation is authoritative: Model Pricing.
Price cut from 2026-10-10: $0.03 → $0.025/image (applies to both gpt-image-2-all and gpt-image-2.5-all).
  • Why: the -all series delivers high image quality on its own and is more stable than the -vip series — -vip is more exposed to provider-side risk controls (we keep maintaining it and adding capacity, and -vip remains available). The cut is meant to make -all the easy default for everyday image generation.
  • Size range: explicit size currently supports common WxH targets with a long edge of 512–1536 pixels. 2K sizes such as 2048x1152 are not currently listed as precisely supported; see 4K model choices for higher-resolution needs.
  • Even lower in practice: $0.025 is the pre-discount price — stack it with the top-up bonus (10%–20% extra credit) and your effective cost drops further.

Choosing a model for 4K

For 4K output, consider Nano Banana Pro, Nano Banana 2, or Nano Banana 2.1. The official-relay GPT-Image 2 / 2.5 series is another option when you need its size and quality controls.Budget for official-relay 4K: 4K combined with higher quality settings can be costly; billing follows actual token usage. Check the target model’s quality tiers, since the same tier name can mean different quality and token budgets across generations. See Model Pricing for current rates.gpt-image-2-vip remains available, but its 4K generation can be slow and inconsistent, so it is not the first choice for 4K requirements.

Group Setup

gpt-image-2-all lives on the Default group — no extra group needed. The reverse channel currently has stable supply, so there’s no enterprise-group fallback story like the official-relay gpt-image-2 has.

Need deterministic URL output → switch to the image2_OSS group

As measured in July 2026 on the default group, gpt-image-2-all (and gpt-image-2-vip) return b64_json when response_format is omitted; pass response_format: "url" explicitly to get an image URL. The default group’s output format is not guaranteed — it has historically defaulted to url with fallback to b64_json under load, and has changed across channel versions. If your business depends on URL output (writing URLs straight to your database, frontend rendering by URL, base64 not acceptable), switch your token’s group to image2_OSS — a group purpose-built for deterministic URL output, at a 1x multiplier (no surcharge), effective for both reverse models gpt-image-2-all and gpt-image-2-vip. It guarantees the response always carries an image URL and never falls back to base64.
Token creation screen: billing mode pay-as-you-go first, group image2_OSS (1x multiplier), a group that outputs image URLs, suited for gpt-image-2-all and gpt-image-2-vip

Token creation: set billing mode to "pay-as-you-go first" and pick the image2_OSS group (1x) — use it when you need deterministic URL output

Advanced (when you also use gpt-image-2-vip and the official-relay gpt-image-2): if your token covers all three models, set the token’s group priority like this:
  • First priority: image2Enterprise (1.2x enterprise group, dedicated stable lane for the official relay)
  • Default fallback: Default (both reverse models live here and route by model)
Result: official-relay gpt-image-2 rides the enterprise lane for stability, while the two reverse models stay on the default group — one token covers all three, no interference.
📖 About the image2Enterprise group: /en/live/2026-04/image2-enterprise-stable

Technical Specs

A 1536x1536 result may involve interpolation; those pixel dimensions do not imply native detail or lossless enlargement. 2K sizes such as 2048x1152 are not currently listed as precisely supported. For higher-resolution needs, see 4K model choices; for full official-API field parity, see gpt-image-2.
⏰ Image URL validity: ~1 day (default)The url field of a url-mode response is an R2 CDN link that expires in about 24 hours — requests after that will 404. For images that need long-term retention (product shots, user artwork, history records, etc.), download and persist them to your own storage as soon as possible after generation.Two common approaches:
  • Server-side download: as soon as you receive the response, use requests / fetch to pull the image and store it in S3 / OSS / R2 / local disk
  • Use b64_json response format: you get the image as base64 data directly, skipping the extra cross-origin download — perfect for frontend rendering or writing straight to a file

Endpoints

Use the OpenAI Images API (/v1/images/generations + /v1/images/edits), for two reasons:
  1. More stable: upstream resource supply for the Images API channel is more plentiful, so call success rates are higher
  2. Shared endpoint format for easier switching: the official-relay gpt-image-2 uses the same Images API endpoints and WxH size format. When switching models, check the destination model’s supported sizes and parameter list.
There is also a chat-based endpoint (/v1/chat/completions, no longer recommended) — see the FAQ below.
Domain options: api.apiyi.com is the main domain. You can also use alternate gateway domains such as b.apiyi.com. Response behavior is identical.
Specifying target dimensions: pass size, for example 1024x1024. It takes priority over dimensions or aspect ratios described in the prompt. Omit size or pass auto to preserve native behavior.

Size and Aspect Ratio Control

gpt-image-2-all now supports the size parameter for target dimensions while retaining the ability to describe dimensions and aspect ratios in the prompt.
  • Explicit size: the supplied WxH is the priority target, including when it differs from dimensions or ratios in the prompt.
  • Native behavior: either omit the size field or send auto as its value. Both options preserve native output; the model chooses dimensions using the prompt and composition.
  • Currently supported targets: common WxH sizes with a long edge of 512–1536 pixels, including 512x512, 1024x1024, and 1536x1536, plus dimensions that are not multiples of 16. This range applies to explicit targets; native outputs below may have longer edges.
1536x1536 may involve interpolation; do not equate its dimensions with native detail or lossless enlargement. 2K sizes such as 2048x1152 are not currently listed as precisely supported. If your workflow requires exact dimensions, check the returned image’s actual width and height before using it.

Supported explicit sizes and request example

The common target examples below are not an exhaustive allowlist. Use a lowercase x in WxH. Verify the returned image’s actual dimensions when your workflow has strict requirements.

Native sizes: verified “prompt phrasing → actual resolution” table

The 8 phrasings below and their observed native dimensions remain reference values for requests with size omitted or set to auto. Put the first-column phrasing at the start of your prompt to guide composition. These measurements are references rather than a guarantee of exact dimensions on every request:
Notes:
  • These native measurements sit in the ~1.5K-pixel tier (longest edge roughly 1500–2000 px); they describe native behavior rather than the accepted range for explicit size targets.
  • Reproducibility is highest when the prompt only contains a phrasing from the table; mixing in other composition words can cause drift.
  • The Chinese strings are the actual values you send; we recommend keeping them as-is rather than translating.

Stylistic phrasings (no fixed resolution)

With size omitted or set to auto, the phrasings below have no fixed verified resolution. Use them as composition or style guidance; pass an explicit size when you want a target such as 1024x1024:
Tip: Put size/composition words at the beginning of the prompt for better adherence.

Exposing this table to your end users

You can offer a “Target size” selector for supported explicit size values, and a separate “Native / auto” mode that uses the 8 prompt prefixes above:
  • For target-size options such as 512x512, 1024x1024, or 1536x1536, send the selected value as size.
  • For native / auto mode, omit size or send auto, then prepend the selected composition phrasing to the user’s prompt.
  • Label native dimensions as observed reference values, so users do not mistake them for exact guarantees.
The following prompt-prefix example is for native / auto mode:
Prompt-based dimensions remain adaptive in native / auto mode. An explicit size is the priority target; avoid promising pixel-perfect output on every request, and verify actual dimensions when your application requires them.

Best Practices

1

Compress input images to under 1.5MB (image edit / multi-image fusion)

Compress each image you upload to under 1.5MB (JPEG quality 80-90 / down-sized resolution); apply the same cap per image in multi-image fusion. Sporadic server-side errors are most often triggered by oversized inputs — compressing measurably improves success rate and latency. An explicit size sets the priority target for output dimensions. Omitting size or setting it to auto preserves native behavior. Input file size does not determine output dimensions. Stuffing 4K / 8K into the prompt does not establish support for those dimensions. Use supported size targets, or the native prompt table above for composition guidance.
2

Choose a target size or native behavior

Pass size for a target such as 1024x1024. Omit it or pass auto for native output; in that mode, put ratio, resolution, and composition words at the start of the prompt for better adherence.
3

Use text elements confidently

Text rendering fidelity is a key selling point — signs, posters, infographics with Chinese/English text all work well.
4

Annotate multi-image order

The order in which you repeat the image field is meaningful. Reference explicitly as “image1/image2/image3” in the prompt.
5

Choose response format by need

Use b64_json for direct web rendering; url for server-side storage/forwarding.
6

Use a 300s timeout

Typical generation is 30–60s, but image upload / download time and reverse-channel peak tails make actual end-to-end time vary widely. Set 300s as a conservative baseline to avoid frequent false timeouts.
7

Trim rejected parameters

gpt-image-2-all does not support n, quality, or aspect_ratio — omit these fields. size is supported; use a common WxH target with a long edge of 512–1536 pixels, or auto.

Error Codes and Retries

Client recommendations:
  • Request timeout starting at 300 seconds (conservative; typical 30–60s, but image upload / download and reverse-channel peak tails cause wide variance — 120s causes frequent false timeouts)
  • Use exponential backoff for 5xx and timeouts (2–3 retries recommended)
  • Log the request-id response header for debugging

FAQ

Both are reverse-engineered channels with an identical call format; -all costs $0.025/call and -vip $0.03/call. The differences include supported size ranges, generation time, and stability:
  • Want faster and steadier output with common target sizes → gpt-image-2-all (~30–60s, size targets with a long edge of 512–1536 pixels, or native / auto output guided by the prompt).
  • Need a different preset size → check gpt-image-2-vip’s supported list. Its 4K generation can be slow and inconsistent, so it is not the first choice for 4K.
  • Need 4K → see 4K model choices for Nano Banana Pro / 2 / 2.1 and official-relay GPT-Image 2 / 2.5. Official-relay 4K with higher quality settings can be costly.
  • Need a quality knob or full OpenAI-API field parity → use the official gpt-image-2.
No. This model returns 1 image per call. For N images, call the API N times in parallel. Each call is billed independently at $0.025.
No. This model returns 1 image per call — for multiple images, use repeated / concurrent calls instead.⚠️ Important: if you pass n=3 in the request, billing will be 0.025 × 3 = $0.075, but only 1 image is actually returned. Make sure to drop the n field from your requests to avoid wasted charges.
This is a reverse-engineered channel using synchronous chat-style responses. Outcomes split into two cases with different billing rules:1) HTTP 5xx returned → NOT billedWhen upstream content policy hard-blocks the request, you’ll see something like:
These hard errors are not billed. Ask the user to adjust the prompt and retry.2) HTTP 200 with a text “soft refusal” → BILLEDWhen the model soft-refuses inside the conversation (e.g. “I can’t do that”, “Sorry, this request involves…”), at the protocol level it looks like a normal chat completion, so it is billed. The reverse channel cannot reliably distinguish “refusal text” from “image output” at the protocol layer.Why we can’t just waive soft refusalsAuto-waiving every soft refusal would mean the platform absorbs every failed upstream call. More importantly, frequently triggering upstream content safety also raises the risk of the supplier’s account being banned — that’s a real supply-side cost we can’t fully eliminate.Recommendations for integrators
  • ✅ Pre-filter and warn users: add a keyword/scenario filter at the frontend or gateway (real-person names, copyrighted characters, sensitive topics) and surface a UI hint like “Celebrity / IP topics may fail and still be billed by upstream policy.” This cuts wasted charges sharply.
  • ✅ Monthly reimbursement for consumer products: we understand consumer-facing products can’t fully gate user input. If your monthly spend is large enough ($1000+/month), you can batch your logs monthly (short-latency calls are usually soft refusals) and contact support for a one-off manual credit — no need to file per-call appeals.
📖 Related: 500 errors are usually content-policy hits (not billed)
Detect first, then handle. As verified in July 2026, the returned b64_json is raw base64 without the data: prefix — decode it to write a file, or prepend the prefix yourself before rendering; earlier versions did include the prefix. Add a startsWith('data:') check in your code: if the prefix is present, use the value directly as img src; if not, decode or prepend first — this avoids double-prefixing or decoding a prefixed string into a broken image.
Writing 1024x1024 only in the prompt guides composition; it does not replace an explicit target. Send size: "1024x1024" to make it the priority target. Omit size or pass auto to retain native adaptive output.The native prompt table above remains a reference for requests where size is omitted or set to auto. If dimensions are a strict requirement, verify the final image’s actual width and height.
Yes, strongly recommended. Compress each input image to under 1.5MB (JPEG quality 80-90 / down-sized resolution): sporadic server-side errors are most often triggered by oversized inputs, and compressing measurably improves success rate and latency. Note: 1.5MB is the recommended ceiling for reliability and speed; the 10MB number in the FAQ above is the gateway hard limit.An explicit size sets the priority target for output dimensions. Either omit the size field or send auto as its value to preserve native behavior. Input file size does not determine output dimensions.Writing 4K / 8K in the prompt does not establish support for those dimensions. Use the supported size range for target dimensions, and the native prompt table for composition guidance in auto mode. For 4K requirements, see 4K model choices above.
Recommended ≤ 10MB per image, formats png / jpg / webp. Overly large images may hit gateway limits. Each image in multi-image fusion must meet this limit.
The url field of a url-mode response is an R2 CDN link that expires in about 1 day (24 hours) — requests after that will 404.Strongly recommended: download and persist generated images to your own object storage (S3 / OSS / R2), CDN, or database shortly after generation. Don’t hotlink the returned URL long-term.Two recommended approaches:
  • Server-side proxy: immediately requests.get(url) after the response, store to your own storage, and return your own URL to the frontend;
  • Use b64_json: add "response_format": "b64_json" to your request to get base64 image data directly — one less cross-origin download, ideal for frontend rendering or writing straight to a file.
For short-lived previews (single-session display), the R2 URL works as-is without persistence.
No. This model returns the image in one shot; streaming is not supported. If latency matters, show a “generating…” progress indicator on the client side and configure a 300s timeout (conservative).
Yes. Point base_url to https://api.apiyi.com/v1 and read api_key from the APIYI_API_KEY environment variable. You can pass size="1024x1024", omit it, or use auto. Inspect your final request to ensure it does not include unsupported n, quality, or aspect_ratio fields. Raw HTTP calls with requests / fetch are also supported.
This model natively supports Chinese, and results are comparable. For Chinese-specific scenarios (calligraphy, traditional festival elements), Chinese phrasing feels more natural.
Yes, the endpoint still works, but it is no longer recommended — use /v1/images/generations and /v1/images/edits instead (more stable, and the same code works with the official-relay gpt-image-2).The chat-based style only makes sense in two scenarios: multi-turn iterative editing, or passing online image URLs directly. Note that when the image intent is ambiguous, the model may return plain text instead of an image (prepend a fixed prefix like “Generate an image:” to your prompt to reinforce it).For full parameters, see the chat-based API reference.
gpt-image-2-all is a reverse-engineered channel. Behavior is aligned but pricing/capabilities may not fully match the official version. For the official direct version, see GPT-Image-1.5.