Model Cards
| Model | Official Model ID | Billing | Notes |
|---|---|---|---|
| Nano Banana Pro | gemini-3-pro-image-preview | Fixed per-request $0.09/req (approx. ¥0.63; approx. ¥0.55 after top-up promotions) | Highest quality |
| Nano Banana 2 | gemini-3.1-flash-image-preview | Per-request $0.055/req (recommended for 4K output); or dynamic token-based billing, 2K approx. $0.04 | Best value |
| Nano Banana 2 Lite | gemini-3.1-flash-lite-image | Fixed per-request $0.025/req; or token-based billing approx. $0.018/req (40% of official price) | Fastest & cheapest, 1K only |
| Nano Banana (Gen 1) | gemini-2.5-flash-image | Fixed per-request $0.02/req | Cheapest |
For a complete price comparison, per-request vs. token-based billing, and token selection advice, see Nano Banana Series Pricing.
Size Control
- Follow the source image ratio: simply omit
aspectRatio; in multi-image editing scenarios, the size of the last image takes precedence - Resolution
imageSize: supports1K/2K/4K- Nano Banana (Gen 1) supports 1K only
- Nano Banana 2 adds 512px
- Nano Banana 2 Lite supports 1K only (no 2K/4K/512px)
How to Integrate
Official Documentation
- Google official docs:
ai.google.dev/gemini-api/docs/image-generation - To integrate with APIYI, just replace the request URL + KEY with APIYI’s; all other parameters are identical to the official ones
Checking Official Status (diagnosing upstream issues)
The Nano Banana series runs on top of Google’s AIStudio / Gemini API. In rare cases, blurry or failing 2K / 4K output can be a problem on Google’s side rather than the integration layer — you can check Google’s official status page (copy and visit it yourself):aistudio.google.com/status.
For example, on Jun 19, 2026 that page reported “Issues with Nano Banana”: Nano Banana 2 / Pro on the Gemini API and AI Studio had problems at 2K or 4K resolution. When you see similar symptoms, compare against the official status page first to quickly tell whether it’s an upstream outage.
APIYI runs the Nano Banana series across dual AIStudio + Vertex channels for redundancy: when one official channel has issues, the other can take over to keep the service available.
Endpoint Support
- Recommended endpoint (Gemini native):
https://api.apiyi.com/v1beta/models/gemini-3-pro-image-preview:generateContent - Supports calls via OpenAI-compatible mode (note: URL upload is not supported, use Base64 instead)
- Does not support
/v1/image/generations
Development Format (Default Recommendation)
- [Recommended] Use the Google native endpoint format
- Images: upload as Base64, download and re-host
- Call method: synchronous multi-threaded calls; asynchronous calls are not yet supported
Input Image Requirements
- A single image cannot exceed 7MB (Google’s rule); if imported via Google Cloud Storage, the per-file limit is 30MB
- Up to 14 images per prompt
- Supported MIME types:
image/png,image/jpeg,image/webp,image/heic,image/heif(thejpgformat is already supported by APIYI) - Base64 size inflation: converting an image to Base64 increases its size by about 33.3% (a 7MB image becomes about 9.3MB)
- APIYI limit: the total volume of images uploaded in a single request must be under 100MB — all calls are synchronous, and oversized payloads can cause memory blowup


docs.cloud.google.com/vertex-ai/generative-ai/docs/models/gemini/3-pro-image
URL Image Input
In addition to Base64, the Gemini native endpoint also supports passing image URLs (image hosts / OSS addresses) directly viafileData.fileUri, eliminating the need for local encoding.
URL upload only works on the Gemini native endpoint; OpenAI-compatible mode does not support URL upload and requires Base64.
Curl Example (fileUri)
Python Example (fileUri)
Billing Basics (Important)
- Synchronous call duration: Pro / 2 at 4K take a reasonable generation time of approx. 30–150s
- Disconnecting on timeout still incurs charges: for example, if generation takes 120s but the client sets the timeout to 100s and disconnects, you are still charged
- 429 / 503 are not charged: failed requests are not billed (we try not to keep customers waiting or stuck without an image)
- Content-safety refusals still incur charges: when a customer’s input has content-safety issues and Google refuses to generate the image, a status code 200 is still charged — see error handling and the guarantee plan below
Timeout Settings (Important)
4K image generation takes longer overall, involving stages such as image upload, API processing, and Base64 image download (our backend bills by API processing time). Under normal conditions, 4K takes about 50s (excluding polling), but if the client sets the timeout too short, it will disconnect prematurely before generation completes and report an error:
Multi-turn conversational editing (native supports it; reverse models don’t)
The Nano Banana series uses the Gemini native format and supports true conversational multi-turn editing: append each turn’s generated image back intocontents as a role: "model" inlineData, then send the next user instruction. The model edits based on the full conversation history and accumulates changes (e.g. recolor the sofa first, then add an accessory — the earlier change is preserved).
This differs fundamentally from “reverse” image models — be clear on it before integrating:
| Aspect | Nano Banana (Gemini native) | Reverse model (e.g. gpt-image-2-all) |
|---|---|---|
| Endpoint | /v1beta/...:generateContent | /v1/chat/completions (chat-style) |
| Multi-turn mechanism | ✅ True conversational: backfill role:model images into contents; the model reads history | ❌ No conversation state: images in assistant history are ignored |
| Cross-turn accumulation | ✅ Supported (red sofa → add hat, sofa stays red) | ⚠️ Re-feed only, one-step edits |
| How to edit the previous image | Backfill the last output as a model image in the conversation history | Pass the previous image URL as the reference in a new user message |
Tested: backfilling the previous image as a
model-role turn lets Nano Banana 2 (gemini-3.1-flash-image-preview) correctly keep editing and accumulate changes; a reverse model only reads the reference image from the last user message, so keeping conversation history does not work for multi-turn there.contents):
Why Do Responses Occasionally Contain Multiple Images
When callinggemini-3-pro-image, you may occasionally see multiple image parts in a single response (2–10 observed in testing), matching sporadic 6000+ (even five-digit) output-token entries in your logs. This is not an anomaly: Google’s official docs state that Gemini 3 image models have “Thinking” enabled by default (it cannot be disabled in the API), the model generates interim images to test composition and logic, these drafts appear in parts alongside the final version, and “the last image within Thinking is also the final rendered image” (official docs: ai.google.dev/gemini-api/docs/image-generation). Based on our testing in July 2026 (Google native generateContent format):
| Scenario | Images returned |
|---|---|
| Pure text-to-image | Always 1 (even if the prompt explicitly asks for “multiple images”) |
| Simple image editing (add accessories / change background / restyle) | Always 1 |
| Complex task-style editing (e.g. “4-view character sheet + outfit change + white background” with multiple constraints) | 2–10, consistently reproducible |
thoughtSignature field, without a thought: true flag); Google’s docs say Thinking generates at most two interim images, but we observed up to 10 on complex tasks.
Billing impact: each image is billed at a fixed token count (1120 tokens per image at 1K/2K resolution, 2000 at 4K), so output tokens grow strictly linearly with the number of images. A sporadic 6000+ (up to ~13.5k in extreme cases) output-token entry in your logs is simply a 4–10 image response, not a billing anomaly.
Recommended downstream code:
- Always iterate over parts — do not assume one image per response; any per-image counting or saving logic must go by the actual number of parts
- Take the last image when you only need one: the earlier drafts have unfinished details and slightly lower quality, so avoid taking the first
- Controlling the image count via the prompt is largely ineffective (in testing, “output only one image” instructions were ignored) — handle it in code
- Multi-image responses take 35–142s (at 1K resolution, longer with more images), noticeably longer than single-image ones — keep the timeout recommendations above (≥ 5 minutes)
FAQs
Error Handling Guide
The three key indicators for diagnosing failed generations, content moderation policies, and friendly prompt strategies
Must-Read Common Dev Questions
Troubleshooting failed generations and common questions
Failed Generation Guarantee Plan
For failures not caused by your input, credits are reimbursed per the number of failed requests
Why do I get connection reset by peer / write_response_body_failed (500)?
Why do I get connection reset by peer / write_response_body_failed (500)?
The full error looks like:This is usually caused by oversized image uploads — the request body gets too large and the connection collapses. Follow these best practices:
- Limit the image count: stay within the official rules (max 14 images per prompt — see the official spec above).
- Limit per-image size: keep each image under 5MB — the official per-image cap is 7MB, and base64 encoding inflates size by roughly 1/3, so leave headroom.
- Compress on the frontend before uploading: compress images on the frontend (or a server-side relay) before sending them to the API — common practice is capping the longest edge, converting to JPEG/WebP, and tuning the quality parameter.
- Switch to URL input: the Gemini native format supports passing an image URL via
fileData.fileUri, sidestepping oversized base64 request bodies entirely — see URL Image Input above.
Use Cases
- AI chat clients: clients such as Cherry Studio can be configured to generate images directly via APIYI
- Generation testing: quickly verify model performance in a chat client or the console
Advanced Needs
- Want to upload images via URL? The Gemini native endpoint supports passing an image URL through
fileData.fileUri; however, OpenAI-compatible mode does not support URL upload, so use Base64 instead. See the code examples and caveats in URL Image Input above. - Want to get a download URL directly (instead of Base64)? Use the NB-OSS group — see Nano Banana OSS Group.