← All writing

Preparing Mantle for the Next Gemini Model Change

A code-level look at the seams, configuration, validation, and tests that make Mantle's Gemini models easier to replace.

Gemini models change quickly. Mantle now treats those changes as configuration work instead of an application-wide rewrite.

The current model profile uses gemini-3.7-flash for brand strategy and gemini-3-pro-image for logo generation and editing. Both are stable endpoints.

Why we made the change

Mantle previously depended on preview model names. Google shut down gemini-3-pro-preview and gemini-3-pro-image-preview, requiring replacements on different schedules.

We used that migration to reduce the amount of code that needs to change the next time a model moves.

Code review

The review focused on where Gemini-specific decisions reached into the application.

The result is a much smaller provider surface:

  • App.tsx creates a brand studio and calls product-level operations. It does not select Gemini models.
  • BrandStudio.ts defines the operations Mantle needs: generate a brand, regenerate or refine a logo, and create variations.
  • geminiBrandStudio.ts is the Gemini adapter. Prompts, SDK calls, response extraction, and provider error handling stay there.
  • geminiModelProfile.ts contains the active text and image model identifiers in one place.

The review also confirmed that every image path—initial logos, regeneration, refinement, and variations—uses the image entry from the same model profile. The strategy path uses the strategy entry.

What makes the next swap easier

One model profile

The deployed identifiers now live in one explicit profile:

  • Strategy: gemini-3.7-flash
  • Images: gemini-3-pro-image

Changing a model no longer requires searching through UI components or multiple service functions. Text and image models can also move independently.

A provider-neutral interface

The application depends on the BrandStudio interface rather than the Google SDK. Mantle's UI works with its own requests, results, and error types.

That keeps provider details behind the adapter and gives us a clear seam for testing—or for adding another provider later.

Validation at the boundary

Structured output alone is not enough. The adapter parses Gemini's response and validates the fields Mantle requires before returning a BrandIdentity.

Image responses are checked for usable inline image data. Invalid inputs and missing outputs become explicit BrandStudioError values instead of leaking provider response shapes into the UI.

Tests for the seam

The adapter tests inject a temporary model profile and verify that strategy requests use the strategy model while every logo request uses the image model.

They also cover malformed structured output, provider authentication failures, and invalid image input. Those tests make a future model swap easier to review because the contract around the model stays fixed.

What still matters during a model change

A passing request is only the first check.

For strategy output, we still need to evaluate palette quality, contrast, light and dark themes, typography, voice, and tagline usefulness. For images, we need to check prompt adherence, background isolation, refinement consistency, and whether simplified, monochrome, and outline variations remain recognizable.

Latency and cost should be reviewed separately for strategy and image work. The architecture now lets us change either path without coupling their rollout.

The takeaway

Model names will keep moving. Mantle is prepared by keeping the model profile small, the application contract stable, provider behavior isolated, and the boundary covered by tests.

The next swap should be a focused adapter change followed by product-quality checks—not a search through the entire application.

Sources