СТАТТЯ

Gemini pricing 28.10 після cutover NB2 (29.10): перерахунок bulk-jobів Bubble-каталогу в BIAIG на Nano Banana 2.1

Віталій Дорошенко Опубліковано

Після зміни model ID на `gemini-nano-banana-2.1` я перераховую не лише $ за картинку, а й input-токени, batch vs sync, chunk size під Bubble Data API і WU — без покладення на непідтверджену дату вимкнення NB2.

Навіщо replan саме зараз

У мене в редакційному календарі стоїть 29.10.2026 — cutover з Nano Banana 2 (gemini-3.1-flash-image) на Nano Banana 2.1 (gemini-nano-banana-2.1) через шар оркестрації BIAIG (Bubble + Gemini для масових jobів каталогу). Я зайшов на публічні сторінки Google 29.10.2026 UTC: у таблиці deprecations і release notes для NB2 досі формулювання на кшталт «no shutdown date announced». Треті сторони (liteLLM, преса) називають 29.10. Для продакшену я сприймаю це як сигнал перевірити live endpoint, а не будувати бюджет лише на заголовку digest. Про це окремо: 29.10.2026: вимкнення Nano Banana 2.

Рядок Gemini API pricing 28.10 у digest я зіставив з фактом: сторонній diff 28.10 на pricing-сторінці класифікується як наавігація (посилання API CLI), без числових змін тарифів; 27.10 додали billing-copy: thinking tokens і grounding-related internal tokens йдуть у billable usage. Формули нижче — з поточної таблиці Gemini Developer API pricing, не з headline alone.

Що змінилось у моделі (коротко)

Параметр NB2 NB2.1
Model ID gemini-3.1-flash-image gemini-nano-banana-2.1 (GA 06.10.2026)
512px (0.5K) output було немає — мінімум 1K
Batch API так (−50% vs Standard) так; SLO ~24h, часто швидше

Якщо каталог тягнув thumbnails 512px — replan у мене торкається storage, CDN і token math, не лише рядка model у BIAIG.

Перерахунок $: output дешевший, input може «з’їсти» економію

Для 1K image output (еквіваленти на pricing-сторінці):

  • Standard: NB2.1 $0.0336 vs NB2 $0.067 за image — майже 2× дешевше на output.
  • Batch: $0.0168 vs $0.034 — та сама логіка 50% від interactive (Batch API).

Input (Standard, $/1M tokens): NB2 $0.50 → NB2.1 $1.50 (3×). Batch input: $0.25 → $0.75. Job з довгими промптами, reference images або multimodal ingest не можна рахувати лише «$ за картинку 1K» — я це вже бачив на таблицях, які дивляться тільки на output.

4K: різні token counts на resolution (наприклад, 3780 vs 2520 tokens у порівнянні NB2.1/NB2 у Scout-пакеті) — я оновлюю внутрішній cost map у BIAIG після зміни ID, особливо якщо дзеркала aggregator відстають від Google.

Grounding / thinking: окремі рядки тарифів і per-request grounding; увімкнений search grounding або вищий thinking level на NB2.1 додає неочевидні рядки в рахунку після clarification 27.10.

Batch vs sync у контексті Bubble-каталогу

Batch (док): половина interactive-ціни, JSONL для великих image batches, 20MB inline cap, 2GB на input file — для non-urgent генерації зображень каталогу.

Batch vs sync у контексті Bubble-каталогу

Sync / interactive: лишаю для latency-bound (preview, ручні правки, same-day merchandising).

У pipeline (з open questions Scout) я тримаю питання: чи image surface — generateContent (batch-eligible) чи Interactions API (у batch-доку — обмеження на generateContent). Відповідь визначає, чи взагалі batch лягає в BIAIG без рефактору.

Chunk size і WU: два стелі одночасно

Bubble Data API bulk create: max 1 000 things на POST …/bulk, 4 хв на completion (manual). Chunk для запису результатів batch-job має вміщатися в це вікно разом із post-processing.

WU (орієнтири з manual):

  • ~0.1 WU — scheduled API workflow;
  • ~0.6 WU — server workflow action;
  • ~0.1 WU — outbound external API call (Gemini).

Schedule API workflow on a list vs recursive scheduling: у benchmark Bubble ~12k vs ~70k WU на 100k workflows — для масового каталогу recursive «по одному SKU» швидко множить WU разом із одним outbound call на продукт.

Моя replan формула для BIAIG: Gemini $ (input + output + опції) + Bubble WU (оркестрація + запис bulk) + latency SLA (batch до ~24h).

Практичний чеклист replan у BIAIG

  1. Model ID: усі конфіги, env і cost maps → gemini-nano-banana-2.1; перевірити, чи gateway використовує prefixed id (google/…) — оновити там, де реально білиться.
  2. Probe NB2: чи gemini-3.1-flash-image ще відповідає; fallback policy, якщо Google залишив «no shutdown date».
  3. Resolution: прибрати 0.5K; перерахувати 1K/2K/4K token rows з pricing-сторінки.
  4. Cost sheet: окремі рядки Standard vs Batch; input $/Mtok для prompt-heavy SKU; grounding/thinking — окремо.
  5. Розбиття job: Gemini batch file limits і Bubble 1 000/4 min; один batch file ≠ один bulk POST без проміжного staging.
  6. Оркестрація: list-based schedule замість recursive; мінімізувати server actions на «порожні» кроки.
  7. Не дублювати загальний гайд «−50% aggregator»: для каталогу важливі мій mix input/output, WU і chunk, а не лише batch discount. Про це окремо: Nano Banana 2.1: ~50% API/batch.

Чесні межі джерел

BIAIG у публічній документації Bubble+Gemini не знайдено (Scout) — ця стаття описує методологію replan для внутрішнього шару, який я вже використовую. Shutdown 29.10 не підтверджений first-party таблицею на день fetch; pricing 28.10 не означає автоматично нових NB-ставок — я звіряюся з pricing і deprecations.

Джерела (межа статті)

Google: pricing, deprecations, changelog, model card NB2.1, image generation, Batch API. Bubble manual: Data API bulk, workload activity types, bulk methods compared. Scout: rewindex 27–28.10, third-party shutdown signals (liteLLM, преса) — лише для конфлікту дат, не як єдине джерело істини.

Схожі статті

← Усі статті