Building a Wallpaper Variation Pipeline with Gemini 3.2 Flash Image Output — How an Indie Developer Splits the Work with Imagen 4 and Cut Monthly API Cost

Python Implementation — Working Code and Why It Looks This Way

The base implementation, using the google-genai SDK as of May 2026:

import os
from google import genai
from google.genai import types
from io import BytesIO
from PIL import Image
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
def generate_variations(base_image_path: str, variation_type: str, count: int = 3):
    """Generate `count` derivative variations of the base image."""
 
    with open(base_image_path, "rb") as f:
        base_image_bytes = f.read()
 
    prompts_by_type = {
        "color": "Keep the subject and composition of this wallpaper. Re-render it with a warm sunset palette. Produce three distinct interpretations, each with a different hue family.",
        "time": "Keep the subject of this wallpaper. Shift the scene to a moonlit night sky with stars.",
        "mood": "Keep the composition. Shift the scene to a rain-washed, slightly misty atmosphere with a quiet, still mood.",
    }
 
    prompt = prompts_by_type[variation_type]
    outputs = []
 
    for i in range(count):
        response = client.models.generate_content(
            model="gemini-3.2-flash-image",
            contents=[
                types.Part.from_bytes(data=base_image_bytes, mime_type="image/png"),
                prompt,
            ],
            config=types.GenerateContentConfig(
                response_modalities=["TEXT", "IMAGE"],
                temperature=0.8,
                seed=42 + i,
            ),
        )
 
        for part in response.candidates[0].content.parts:
            if part.inline_data is not None:
                outputs.append(part.inline_data.data)
 
    return outputs

Three deliberate choices worth calling out.

First, the seed varies per request. Holding a single seed across three calls returns three near-identical images. A simple 42 + i offset is more than enough to break out of mode collapse. If you forget this you spend an afternoon wondering why temperature does not work.

Second, temperature=0.8 is the sweet spot I converged on for variation work. Zero is deterministic, which kills the point of "variations." I tested across 0.6 to 0.9 and 0.8 produced the most consistent mix of fresh-but-coherent results across my wallpaper categories.

Third, the response_modalities order is not cosmetic. Gemini tends to emit text first and image second, so listing ["TEXT", "IMAGE"] in that order matches the natural generation flow and keeps log readers from getting confused. The text portion frequently contains a short description of what was changed, which I capture into structured logs for later debugging.

For parallel execution, switching to asyncio.gather() over three coroutines lands the three images in roughly the time of a single call (1.0 to 1.2x). At higher throughput you hit Gemini-side rate limits, so I gate concurrent calls per IP and per user with a semaphore on the worker.

The Monthly API Cost — Real Numbers

For an indie developer, this is the section that decides whether the feature ever ships.

Variation generation in my apps lives behind a Premium plan at 580 JPY per month. The median Premium user invokes variation generation about 18 times per month. Each invocation produces three images, so the median user generates 54 images per month.

At roughly $0.03 per output image for Gemini 3.2 Flash Image Output (my measured range is $0.025 to $0.035 depending on input image size and output resolution), the per-user API cost is 54 × $0.03 = $1.62 per month, or about 250 JPY at current rates.

580 JPY revenue minus 250 JPY API cost leaves 330 JPY of gross margin per Premium user. That is a 57 percent gross margin, before the AdMob revenue from those same users which is the larger pool. Premium conversion sits around 1.2 percent in my apps. I do not need Premium to pay for itself; I treat it as a retention and eCPM lift indicator.

With this cost structure I can afford to give every new install one free variation generation. That first sunk cost is 3 × $0.03 = $0.09 per trial, and 4.2 percent of those trial users convert to Premium within 30 days. Combined with the AdMob lift, even non-converters pay for the trial. The shape of the funnel only works because the per-image cost is this low.

The equivalent feature built on Imagen 4 would cost 1.5x more and run 1.8x slower because you need a two-step Vision → Imagen 4 pipeline to handle the "derive from an existing image" pattern. For variation use cases, Gemini 3.2 Flash Image Output is the realistic answer.

Three Traps That Bit Me in Production

Trap 1: Mode Collapse Even With Temperature Up

My first naive implementation kept the seed fixed across the three calls. All three responses came back near-identical. That mistake is obvious in hindsight but the deeper version is subtler — even with seed variation, an over-specific prompt collapses outputs. "A warmer sunset palette" tends to produce one canonical sunset that does not budge much.

The fix I converged on is dual: vary the seed, and bake explicit variation axes into the prompt. Instead of one prompt, I generate three sub-prompts: "warm amber sunset," "blue-tinged dusk," "pink magic hour." Combined with seed variation, the three returned images are reliably distinct.

Trap 2: SafetySettings Silently Eating Outputs

Default safety thresholds will block darker palettes and any wallpaper where a human silhouette appears even faintly. The symptom is "the output is just empty" with no clear error. The diagnostic is response.candidates[0].finish_reason == "SAFETY".

I relaxed two categories to BLOCK_ONLY_HIGH after diagnosing:

config=types.GenerateContentConfig(
    response_modalities=["TEXT", "IMAGE"],
    temperature=0.8,
    seed=42 + i,
    safety_settings=[
        types.SafetySetting(
            category="HARM_CATEGORY_HARASSMENT",
            threshold="BLOCK_ONLY_HIGH",
        ),
        types.SafetySetting(
            category="HARM_CATEGORY_HATE_SPEECH",
            threshold="BLOCK_ONLY_HIGH",
        ),
    ],
)

I do not drop categories to BLOCK_NONE. iOS App Store review feedback and the fact that children sometimes use wallpaper apps both argue for keeping a floor of filtering. The blocked-output rate fell from 11 percent to about 0.6 percent after this change, which is a workable cost.

Trap 3: Output Shape Is Not Guaranteed

Even with response_modalities=["TEXT", "IMAGE"] set, you get three possible response shapes back: text only, image only, or both. Client code must loop over parts defensively and only treat parts where inline_data is present as images:

for part in response.candidates[0].content.parts:
    if part.inline_data is not None:
        image = Image.open(BytesIO(part.inline_data.data))
        outputs.append(image)
    elif part.text:
        # capture text for diagnostics, not for the user
        print(f"Model text: {part.text[:100]}")

I also added a retry policy for zero-image responses: try once more with a shifted seed, and if that fails, fall back to the mood variant prompt. End-user-facing failure rate dropped to about 0.4 percent per month.

Caching to Compress Cost Further

The same base image and the same variation prompt come from many different users. A "sakura wallpaper, sunset variation" gets requested by dozens of users in the same week during peak cherry-blossom season. There is no reason to regenerate.

I key generated images by (base_image_id, variation_type, seed) and persist them in Cloudflare R2. Cache hit rate runs around 33 percent, which compresses my real-world API spend by the same 33 percent versus naive billing. The 250 JPY per user number I quoted above already includes this caching effect.

Stale entries get cleaned up by R2 lifecycle policies — anything not read in 60 days is deleted. Operational overhead is effectively zero. I considered using Gemini context cache to share system-prompt tokens, but for Image Output the system-prompt overhead is small and the win is marginal.

Effect on Retention and Conversion

After 30 days of A/B testing this feature against a control cohort, the numbers I am willing to share publicly:

Day 7 retention for Premium users with variations enabled: 42.1 percent versus 38.4 percent for the control. Day 30: 21.4 percent versus 18.2 percent. Both gaps cleared the statistical-significance bar for my sample size.

Premium conversion rate moved from 0.84 percent to 1.21 percent — a 1.44x lift. The interpretation I trust most is that gating variation generation behind Premium gives the plan a concrete, immediately-useful payoff that a "remove ads" pitch cannot match.

eCPM lifted slightly, mostly as a second-order effect: better retention means more sessions per user, which means more ad impressions per user. Day 30 LTV improved by about 19 percent. For an indie developer working alone, double-digit percentage swings of this size are how a business actually keeps going.

Who I Recommend This Pattern For

I recommend this stack for any indie developer whose app already has a catalogue of image content where users can pick one item and reasonably ask for "more like this with a twist." Beyond wallpapers, that includes recipe apps showing plating variants, fashion apps showing colourways of the same item, cover-art apps for books or albums, and anywhere personalisation can be expressed as "same subject, different palette."

If your use case is greenfield generation rather than derivation, lean on Imagen 4 as the primary engine. Image Output is purpose-built for the derivation case, and I think the cleanest production design uses both — Imagen 4 for seed content, Image Output for user-driven variations.

If you are starting today, the fastest way to feel out the difference is to send a single image-plus-prompt request to gemini-3.2-flash-image with response_modalities=["TEXT", "IMAGE"] and see how the returned parts are shaped. The interface is leaner than Imagen 4's image-generation endpoint and the input-image handoff is just Part.from_bytes.

Both my grandfathers were temple carpenters. The way they cared about the parts of a structure that people touch every day has stayed with me as a working principle for software. Variation generation lives in a place users touch every session, so I think it deserves a deliberate cost-quality-latency design rather than a quick prototype that survives by accident. The next thing I am exploring is using context cache to remember user-specific taste history and produce "variations tailored to you" as a higher-tier Premium feature. The cost economics look workable if cache hit rates stay above 20 percent.

Before writing any code, I would suggest sketching the monthly active user count and current Premium conversion rate for your app on paper. Backing out the gross margin first turns the decision from a leap into a calculation. Thank you for reading.