Rebuilding My Wallpaper App's Color Variations on Nano Banana 2 — Life After the Imagen 4 Shutdown, and Why Resolution Decides the Margin

The pipeline, stage by stage

Here is what runs the moment someone taps "see color variations" on a wallpaper detail screen. I list the failure handling next to each stage, because that is where monitoring eventually goes.

Every generation request goes through the backend. Calling the API straight from the client breaks down on both key management and usage control, and I won't bake a key into an app I give away for free.

Splitting stages 6 and 7 is what the whole cost argument rests on. You don't pay delivery-resolution prices for pictures nobody chose — that's the entire trick.

Resolution decides the margin

This is where the migration actually hurt. The pricing footnotes are explicit: image output is billed as tokens, with a published equivalent per resolution. On Nano Banana 2 Standard, 1K is 1,120 tokens at $0.067, 2K is 1,680 tokens at $0.101, and 4K is 2,520 tokens at $0.151.

Wallpapers are tall, and delivery starts at 2K. So for this app the per-image price is set by resolution, not by which model I picked. Here's what the obvious approach costs, using my own usage (median 18 uses per Premium user per month, three candidates per use).

My app's Premium tier is ¥580 a month, roughly $3.90 at ¥150 to the dollar. Read the first row again: generating everything at 2K spends $3.65 of that on the API even after caching. The margin is pennies. The second row, 4K for everyone, costs more than the subscription brings in.

The two-stage split lands the same experience at $2.43 — 33% below the flat-2K row, and 44% below flat 4K. Running those numbers is what told me the migration wasn't really about the call signature.

Anything that doesn't have to happen right now can go to Batch, which halves it again: Nano Banana 2 Batch bills image output at $30 per 1M tokens, so 1K comes to $0.034 an image. Seasonal seed images go to Batch; anything a user is waiting on goes to Standard.

Candidates cheap, the chosen one expensive. That line I intend to keep even after the next price revision.

Machine acceptance for what comes back — pHash and hue

Even with three distinct instructions, one candidate in three still comes back looking almost like the base image. At full size the difference is visible; at thumbnail size it slips past whoever is reviewing. The user sees the candidates side by side, so one near-duplicate reads as a broken feature.

So an acceptance check runs right after generation. A perceptual hash drops candidates that are too close to the base, and candidates that are too close to each other.

from io import BytesIO
from PIL import Image
import imagehash
 
# thresholds picked after measuring the distance distribution on my own catalog
MIN_DIST_FROM_BASE = 8      # below this it's effectively the base image
MAX_DIST_FROM_BASE = 26     # above this it's a different picture
MIN_DIST_BETWEEN = 6        # minimum distance between accepted candidates
 
 
def perceptual_hash(image_bytes: bytes) -> imagehash.ImageHash:
    image = Image.open(BytesIO(image_bytes)).convert("RGB")
    # normalize first so a different output resolution doesn't move the hash
    return imagehash.phash(image.resize((256, 256)))
 
 
def accept_variations(base_bytes: bytes, candidates: list[bytes]) -> list[bytes]:
    base_hash = perceptual_hash(base_bytes)
    accepted: list[tuple[imagehash.ImageHash, bytes]] = []
 
    for candidate in candidates:
        candidate_hash = perceptual_hash(candidate)
        distance = candidate_hash - base_hash
 
        if distance < MIN_DIST_FROM_BASE or distance > MAX_DIST_FROM_BASE:
            continue  # too identical, or drifted into a different picture
        if any(candidate_hash - accepted_hash < MIN_DIST_BETWEEN
               for accepted_hash, _ in accepted):
            continue  # too close to one already accepted
 
        accepted.append((candidate_hash, candidate))
 
    return [image_bytes for _, image_bytes in accepted]

On the thresholds: imagehash.phash defaults to 64 bits, so Hamming distance runs 0 to 64. Measuring pairs from my own catalog that a person would call "a color variation", most landed between 8 and 24. The failures where the subject's outline had changed usually came in above 26. Those two measurements set the bounds — and since the numbers move with your material, I'd run the distribution on your own catalog once before adopting them.

Note that this runs at the candidate stage, so rejected images never cost delivery-resolution money. Putting acceptance before or after the expensive stage changes the invoice, not just the quality.

One honest limitation: pHash is built on a DCT of the grayscale image, so it is blunt about variations that only move hue. On the color axis I pair it with the HSV H channel.

import numpy as np
 
 
def mean_hue(image_bytes: bytes) -> float:
    hsv = Image.open(BytesIO(image_bytes)).convert("HSV").resize((128, 128))
    return float(np.asarray(hsv)[:, :, 0].mean())
 
 
def hue_shift(base_bytes: bytes, candidate_bytes: bytes) -> float:
    """Difference in mean H. Used to verify the color axis (0-255 scale)."""
    return abs(mean_hue(candidate_bytes) - mean_hue(base_bytes))

When the type is color, candidates with a hue_shift under 12 get dropped as well. A pure hue change barely moves the pHash distance, and without that one line those candidates sail through.

Caching, which trims the bill further

Different users ask for the same variation of the same base image more often than you'd expect. When a season turns, the same picture and the same color shift cluster into a narrow window.

My implementation caches candidates in Cloudflare R2, keyed on base image ID, type and prompt index. Hit rate sits around 33% — that's the number behind the "after cache" column above.

Cache everything forever and storage starts costing more than generation, so anything untouched for 60 days is deleted, handled by an R2 lifecycle policy I no longer think about.

The adopted high-resolution image is treated differently. Candidates are disposable, but the one a user chose and saved gets asked for again later, sometimes on a new device. Candidates for 60 days, adopted images indefinitely — that one distinction changed the kind of email I get.

Finding retired model IDs still sitting in your code

What bothers me about the Imagen 4 shutdown is how I found out: by re-reading a page, not by anything breaking. To stop leaving that to chance, I put a script in CI that scans the repository for model IDs and checks them against my own copy of the deprecation table.

The table comes first. A null means no announced shutdown; a date means the endpoint goes away. I keep this hand-maintained on purpose — it's the one place I want to have read with my own eyes.

{
  "gemini-3.1-flash-image": null,
  "gemini-3.1-flash-lite-image": null,
  "gemini-3-pro-image": null,
  "gemini-3.8-flash": null,
  "gemini-3.6-flash": null,
  "gemini-2.5-flash-image": "2026-10-02",
  "gemini-3.1-flash-image-preview": "2026-06-25",
  "gemini-3-pro-image-preview": "2026-06-25",
  "imagen-4.0-generate-001": "2026-08-17",
  "imagen-4.0-ultra-generate-001": "2026-08-17",
  "imagen-4.0-fast-generate-001": "2026-08-17"
}

Then the scanner. It collects anything that looks like a model ID and reports what is retired, what is about to be, and what isn't in the table at all.

#!/usr/bin/env python3
"""List the model IDs left in your code and check them against the deprecation table.
 
    python3 model_id_audit.py <directory>
 
Exit code 1 means something retired, expiring, or unknown is still referenced.
"""
import json
import re
import sys
from collections import defaultdict
from datetime import date
from pathlib import Path
 
TABLE_PATH = Path(__file__).with_name("model_shutdown_table.json")
MODEL_RE = re.compile(r"\b(?:gemini|imagen|veo|lyria)-[0-9][0-9A-Za-z.\-]*\b")
SKIP_DIRS = {".git", "node_modules", "dist", "build", "__pycache__", ".venv"}
SUFFIXES = {".py", ".ts", ".tsx", ".js", ".jsx", ".swift", ".kt", ".json", ".yaml", ".yml", ".toml"}
SELF_FILES = {Path(__file__).name, TABLE_PATH.name}
 
 
def load_table() -> dict:
    raw = json.loads(TABLE_PATH.read_text())
    return {k: (date.fromisoformat(v) if v else None) for k, v in raw.items()}
 
 
def scan(root: Path) -> dict:
    found = defaultdict(list)
    for path in root.rglob("*"):
        if not path.is_file() or path.suffix not in SUFFIXES:
            continue
        if SKIP_DIRS & set(path.parts) or path.name in SELF_FILES:
            continue
        for lineno, line in enumerate(path.read_text(errors="ignore").splitlines(), 1):
            for model_id in MODEL_RE.findall(line):
                found[model_id].append(f"{path.relative_to(root)}:{lineno}")
    return found
 
 
def verdict(model_id: str, table: dict, today: date) -> str:
    if model_id not in table:
        return "not in table (check it yourself)"
    shutdown = table[model_id]
    if shutdown is None:
        return "current"
    if shutdown <= today:
        return f"retired ({shutdown})"
    return f"expiring ({shutdown}, {(shutdown - today).days} days left)"
 
 
def main() -> int:
    root = Path(sys.argv[1] if len(sys.argv) > 1 else ".")
    table, today, found = load_table(), date.today(), scan(root)
    if not found:
        print("no model IDs found")
        return 0
 
    width = max(len(k) for k in found)
    bad = 0
    for model_id in sorted(found):
        state = verdict(model_id, table, today)
        if state != "current":
            bad += 1
        mark = "  " if state == "current" else "!!"
        print(f"{mark} {model_id.ljust(width)}  {len(found[model_id]):>2} hits  {state}")
        if state != "current":
            for hit in found[model_id][:3]:
                print(f"     - {hit}")
    print(f"\nscanned {root.resolve()} / {bad} to fix")
    return 1 if bad else 0
 
 
if __name__ == "__main__":
    sys.exit(main())

Run against a small tree standing in for my pre-migration code — MODEL = "gemini-3.1-flash-image", LEGACY_MODEL = "gemini-2.5-flash-image", SEED_MODEL = "imagen-4.0-generate-001", plus a gemini-3.1-flash-image-preview left in a config file — this is what came back on September 20, 2026.

!! gemini-2.5-flash-image           1 hits  expiring (2026-10-02, 12 days left)
   gemini-3.1-flash-image           1 hits  current
!! gemini-3.1-flash-image-preview   1 hits  retired (2026-06-25)
     - src/config.json:1
   gemini-3.6-flash                 1 hits  current
!! imagen-4.0-generate-001          1 hits  retired (2026-08-17)
     - src/variations.py:3
 
scanned /path/to/app / 3 to fix

The third line is the one I was grateful for. That preview ID lived in a fallback field, which means nothing calls it on a normal day — the tests stay green precisely because it is never exercised. It would have been reached exactly once: on the day the primary path failed in production.

I kept the "not in table" verdict too, because I want to notice unfamiliar IDs — a typo and a line I transcribed wrong show up in the same column.

I count model IDs as dated inventory, not as configuration. Inventory is something you check the remaining days on.

Three traps I hit in production

Nothing runs the way the design says it will. Three places where I tripped.

Trap 1: all three candidates come back identical

Before I split the instructions, I sent one prompt three times and expected variety. I got near-copies. With sampling parameters deprecated, there is no going back to that approach anyway.

Over-specific prompts cause the same thing. Ask only for "a sunset palette" and the model reaches for the sunset it already has. Naming the hue first — reddish, blue-toned, pink — separates them reliably.

Trap 2: the output comes back empty

On dark wallpapers, and on ones where a figure is faintly visible, you sometimes get text and no image. For a while I had no idea why: no exception, just two candidates where three were expected.

Now the first thing I check is whether interaction.output_image is None, and if it is, the request falls through to a different instruction. I left the safety filters where they are. This is an app children may open, and I would rather not argue about it during store review.

Trap 3: the high-resolution redraw isn't the same picture

You pass previous_interaction_id meaning "same thing, bigger", and the composition shifts slightly. The user chose a specific picture, so delivering a different one is simply a failure.

Two guards. The instruction says explicitly not to change subject, hue or brightness. And the redraw is compared against the candidate with the same perceptual_hash; if the distance exceeds 6, the 1K candidate ships instead. Lower resolution, but the picture they picked.

Who I'd recommend this to

This fits if your app already has an image catalog and you want to return derivatives in response to something the user does. Wallpapers aren't special here — plated variations in a recipe app, color options for the same product, seasonal treatments of cover art all take the same shape.

It fits badly if every image is generated from scratch as the main event. There, the candidate stage buys you little, and a single Nano Banana Pro generation gives steadier results. The two-stage split exists so you don't pay premium prices for pictures nobody picked; with no picking, there is nothing to split.

If you want one concrete next step, run model_id_audit.py against your own repository before you research anything else. Counting what you currently point at is faster than looking up where to go. That is where I should have started.

Thank you for reading. If it settles the order in which you check your own dated values, that's enough.