DEV Community: APIKO

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

APIKO — Fri, 30 Oct 2026 10:13:12 +0000

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.

DeepSeek V4 Pro API: what reasoning_effort and max_tokens actually do

APIKO — Tue, 27 Oct 2026 02:20:57 +0000

DeepSeek V4 Pro is a reasoning model: before it answers, it spends tokens thinking, and you pay for those tokens. I wanted to know two things before putting it in production: how much the reasoning_effort setting changes that thinking, and whether max_tokens can be used as a cost cap. So I measured it.

Disclosure: I work on APIKO, the OpenAI-compatible gateway used for these calls. Everything below is plain OpenAI SDK code and should behave the same through any gateway that passes these parameters through.

Setup

# pip install openai
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apiko.app/v1", api_key=os.environ["APIKO_API_KEY"])

QUESTION = ("How many integers from 1 to 1000 are divisible by 3 or 5 but not by 15? "
            "Reply with the number and one short sentence of reasoning.")

reply = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": QUESTION}],
    reasoning_effort="low",   # low | high | max
)
print(reply.choices[0].message.content, reply.usage)

The question is a small counting problem with one right answer (401).

Test 1: does reasoning_effort change anything?

One call per level, same question, run on 2026-10-27 through the DeepSeek V4 Pro API on APIKO:

reasoning_effort	reasoning tokens	completion tokens (billed)	latency	answer
low	266	303	7.7 s	401 ✓
high	285	327	6.2 s	401 ✓
max	330	376	6.9 s	401 ✓

On an easy question the levels barely differ: max thought about 24% more than low, all three got it right, and latency did not follow the effort level at all. One run per level is not a benchmark, so treat this as "the knob is gentle on simple tasks", not as a ranking. For extraction and classification I now default to low; the extra thinking is only worth paying for on problems where low actually gets things wrong.

Notice that completion tokens include the reasoning tokens. In every run, roughly 88% of what I paid for in output was thinking, not the answer.

Test 2: max_tokens is not a cost cap, it is an answer killer

I repeated the high run with max_tokens=64:

{"finish_reason": "length", "content": "", "completion_tokens": 64, "reasoning_tokens": 64}

All 64 tokens went to thinking, and the visible answer came back empty. The call was cheap, but useless. In this test max_tokens capped thinking and answer together, and the thinking came first.

What I took from it:

Don't use max_tokens to save money on a reasoning model. Lower reasoning_effort instead.
If you do set max_tokens, leave room for the thinking (about 300 tokens even for this simple counting question) and check finish_reason. "length" with empty content means the model never got to answer.
Log usage.completion_tokens for every call; that is the number you are billed for.

Small thing that surprised me: the fixed prompt overhead

A bare "Hi" was billed as 84 prompt tokens, and each extra word added about one. So there is roughly an 80-token fixed overhead per request from the chat template. It doesn't matter for long prompts, but if you send thousands of tiny classification requests, it is most of your input cost. Batch several items into one request where you can.

Streaming with usage

If you stream, ask for usage explicitly or you won't get token counts:

stream = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": QUESTION}],
    stream=True,
    stream_options={"include_usage": True},
)
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
    if chunk.usage:
        print("\n", chunk.usage)

Summary

Model id deepseek-v4-pro, 1M-token context, any OpenAI SDK.
reasoning_effort changed thinking only modestly on a simple task (266 → 330 tokens); measure it on your own prompts.
Most of the output bill is thinking. A small max_tokens cuts the answer, not the thinking.
Expect about 80 prompt tokens of overhead per request; batch tiny requests.

Request reference (tools, structured JSON output, streaming): DeepSeek docs on APIKO.

Use one OpenAI-compatible API in LangChain and LlamaIndex

APIKO — Tue, 13 Oct 2026 12:20:14 +0000

LangChain and LlamaIndex both ship first-class OpenAI integrations. Because APIKO AI API speaks the OpenAI API, you can reuse those integrations to reach models from OpenAI, Anthropic, Google, DeepSeek and more: point them at https://api.apiko.app/v1, pass an APIKO key, and pick a model id.

Setup

Create an API key at apiko.app (pay as you go in USD, credit packs from $5, no subscription), then:

export APIKO_API_KEY=sk-...

Model ids come from the model marketplace, which shows live prices and availability for every model.

LangChain

# pip install langchain-openai
import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="claude-sonnet-5-5",
    base_url="https://api.apiko.app/v1",
    api_key=os.environ["APIKO_API_KEY"],
)

print(llm.invoke("Give me three names for a weather app.").content)

Swapping providers is a one-word change, so you can run the same chain against several models:

for model in ["gpt-6-astra", "claude-sonnet-5-5", "gemini-3.5-flash", "deepseek-v4-flash"]:
    llm = ChatOpenAI(model=model, base_url="https://api.apiko.app/v1", api_key=os.environ["APIKO_API_KEY"])
    print(model, "->", llm.invoke("Summarize what an API gateway does in one line.").content)

LlamaIndex

# pip install llama-index-llms-openai-like
import os
from llama_index.llms.openai_like import OpenAILike

llm = OpenAILike(
    model="gemini-3.5-flash",
    api_base="https://api.apiko.app/v1",
    api_key=os.environ["APIKO_API_KEY"],
    is_chat_model=True,
)

print(llm.complete("Explain retrieval-augmented generation in two sentences."))

Why route through one endpoint

One key and one balance for every provider instead of separate accounts.
Automatic routing and failover when an upstream provider has trouble.
Failed calls cost nothing: when an upstream call fails, the amount held for it goes back to your balance automatically.

More examples are in this gist and the docs at apiko.app/docs.

Call GPT, Claude, Gemini and DeepSeek with one OpenAI-compatible API

APIKO — Tue, 13 Oct 2026 11:33:46 +0000

Most AI projects end up talking to more than one model provider. One model is cheaper for drafts, another is better at code, a third handles images. Every extra provider means another account, another API key, another balance to top up and another SDK quirk to learn.

This post shows how to call models from several providers through one OpenAI-compatible endpoint, using APIKO AI API. The code is the standard OpenAI SDK; only the base URL and the key change.

1. Get a key

Create an API key at apiko.app. Billing is pay as you go in USD: credit packs start at $5, the balance works on every model and does not expire, and there is no subscription.

export APIKO_API_KEY=sk-...

2. Point the OpenAI SDK at APIKO

Python:

# pip install openai
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apiko.app/v1", api_key=os.environ["APIKO_API_KEY"])

reply = client.chat.completions.create(
    model="gpt-6-astra",
    messages=[{"role": "user", "content": "In one sentence, what is an API gateway?"}],
)
print(reply.choices[0].message.content)

Node.js:

// npm install openai
import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.apiko.app/v1", apiKey: process.env.APIKO_API_KEY });

const reply = await client.chat.completions.create({
  model: "gpt-6-astra",
  messages: [{ role: "user", content: "In one sentence, what is an API gateway?" }],
});
console.log(reply.choices[0].message.content);

Plain HTTP works too:

curl https://api.apiko.app/v1/chat/completions \
  -H "Authorization: Bearer $APIKO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-v4-flash", "messages": [{"role": "user", "content": "Hello!"}]}'

3. Switch models by changing one string

Because every model sits behind the same endpoint, comparing models is a loop:

for model in ["gpt-6-astra", "claude-sonnet-5-5", "gemini-3.5-flash", "deepseek-v4-flash"]:
    reply = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Explain rate limiting in one sentence."}],
    )
    print(f"{model}: {reply.choices[0].message.content}")

The model ids come from the model marketplace, which shows live prices and availability for every model, measured from real calls and scheduled probes. That makes it easy to check what a model costs before you put it in production.

4. What you get on top of a plain proxy

One key, one balance, one bill instead of separate provider accounts.
Automatic routing and failover when an upstream provider has trouble.
Automatic refunds on failed calls: when an upstream call fails, the amount held for it goes back to your balance.
Works with existing tools: the official OpenAI SDKs, LangChain, LlamaIndex, or anything else that speaks the OpenAI API.

Wrap-up

If your app already uses the OpenAI SDK, trying other models is a two-line change: set base_url to https://api.apiko.app/v1 and swap in an APIKO key. The full set of runnable examples is in this gist, and the docs are at apiko.app/docs.