Nano Banana 2.1 API in production: latency, failures and concurrency from 760 real jobs

#ai #api #gemini #python

Most Nano Banana 2.1 write-ups compare image quality. I needed different numbers before telling customers what to expect: how long a request really takes at 1K, 2K and 4K, how often it fails and why, and what happens when 90 jobs arrive at once. The numbers below come from one week of production traffic plus a load test, all through the same OpenAI-compatible endpoint.

Disclosure: I work on APIKO, the gateway these jobs ran through. The timings include our queueing and polling, so treat them as "what a client waits", not as raw model speed.

The traffic

Seven days, Oct 14–21, 2026: 760 Nano Banana 2.1 jobs from 10 accounts. 92% were edits (prompt plus one or more reference images), and 75% were 2K. So the typical request is an edit with a reference image, not plain text-to-image.

Latency by resolution

Time from submit to finished result:

	p50	p90	p99
all jobs	68 s	116 s	325 s
1K	49 s
2K	75 s
4K	80 s	262 s

4K is barely slower than 2K at the median, but its tail is long: one in ten 4K jobs took over four minutes. Time of day also mattered more than I expected. Jobs during the Asian evening (10:00–16:00 UTC) had a median of 77 s, against 58 s during the Asian daytime.

This is why I would not call the model with a synchronous HTTP request. nginx closes an idle upstream connection after 60 s by default (proxy_read_timeout), and plenty of proxies and serverless runtimes have similar limits, all below the median for a 2K edit.

Failures, and what fixed them

The week had 23 failed jobs (97.0% success):

18 were upstream errors: "busy" or "generation failed", five of them inside one 23-minute outage
3 were reference image URLs the model could not fetch
2 were content refusals

Only the first group is worth engineering around. We started sending a second request when the first one fails fast or runs far past its usual time, and kept whichever finished first. In the 344 jobs after that change, there were zero failures. The cost is extra requests: about 8% overall, and about a quarter of 4K jobs, because 4K has the longest tail.

The other two groups are on the caller: host reference images somewhere the model can reach (or upload them once and reuse the URL), and expect the occasional content refusal.

70 and 90 jobs at the same time

On Oct 24 we fired real community prompts all at the same instant, again mostly 2K edits with some 4K:

	70 jobs	90 jobs
succeeded	70/70	90/90
submit call returned	p50 2.8 s	p50 3.1 s
all results ready	83 s	115 s
2K p50	58 s	66 s
4K p50	68 s	105 s

No rate-limit errors at either level. One request in the 90 run got an instant upstream 504 and was retried transparently. Result files are big: a 2K image was 6–8 MB and a 4K one 18–20 MB, which took 10–16 s just to download. If you show results in a UI, budget for that download as well as the generation.

The client shape that works

Submit asynchronously, poll every few seconds, and give up only after several minutes:

import os, time, requests

BASE = "https://api.apiko.app/v1"
H = {"Authorization": f"Bearer {os.environ['APIKO_API_KEY']}"}

job = requests.post(f"{BASE}/images/edits", headers=H, timeout=60, json={
    "model": "nano-banana-2.1",
    "prompt": "Turn this product photo into a clean studio shot on white",
    "images": ["https://example.com/product.jpg"],
    "resolution": "2k",               # 1k | 2k | 4k
    "async": True,
}).json()

deadline = time.time() + 600          # the 4K tail can pass 4 minutes
while time.time() < deadline:
    time.sleep(5)
    task = requests.get(f"{BASE}/tasks/{job['id']}", headers=H, timeout=30).json()
    if task["status"] in ("completed", "failed"):
        print(task)
        break

Request fields for text-to-image, edits, aspect ratios and tiers are in the API reference; live price and availability are on the Nano Banana 2.1 API page. Result links expire after 24 hours, so copy anything you want to keep.

What I would tell someone integrating it

Plan for a minute or more per 2K edit and set timeouts in minutes, not seconds.
4K costs you mostly in the tail and in file size, not in the median.
A second request on failed or slow jobs removed every upstream failure in the 344 jobs since we added it.
Run your own numbers at your busiest hour. Ours were about a third slower at peak, and a quiet-hour test would have hidden that.

DEV Community