# Add an image generation API without using your final model for every draft

> Use Flash for prompt iterations and Image 2.6 for reviewed finals. Measure the full workflow before choosing a default.
> By Dave · 2026-10-14
> Source: https://otf-kit.dev/blog/mai-image-2-6-in-app-editing


If every prompt tweak in your SaaS image feature goes straight to the model you use for final artwork, you are paying your quality tier to answer questions that a faster draft could answer: did the composition move, did the product stay recognizable, and did the edit follow the instruction?

The new MAI Image 2.6 and MAI Image 2.6 Flash options on Vercel AI Gateway make a two-stage workflow practical to test. Use Flash for early prompt iteration, then route a user-approved or carefully reviewed result through Image 2.6 when quality matters more than speed. That is a workflow recommendation, not a guarantee that your bill will fall. Benchmark it against your own prompts, output settings, retries, and acceptance criteria before choosing a default.

Vercel’s announcement says both models support text-to-image and image editing through the AI SDK or AI CLI, with a single Gateway key and no separate provider account. It describes Flash as faster and lower cost for many iterations, and Image 2.6 as the quality-oriented choice for final assets. The announcement also describes reference-image editing and large outputs. Confirm the current capability and input limits in the model interface you actually use before making them a product promise: the announcement and the live playground can differ in how they present limits.

## Start with the product decision, not the model name

An image feature is a workflow. A user gives your app an intent and perhaps a reference image. Your server validates access, sends the request to a provider, records what happened, and returns a result the user can inspect, revise, save, or discard. The model choice matters, but it is only one part of that path.

For a first version, split the workflow into two explicit stages:

1. **Draft:** the user changes a prompt or selects a composition; your app sends that iteration to the faster Flash model.
2. **Review:** the user chooses a candidate, your app shows the prompt and preview, and a deliberate action requests a final-quality pass from Image 2.6.

![The MAI-Image-2.6-Flash playground showing its prompt field, suggestion prompts, optional reference-image upload and empty result area.](https://cdn.otf-kit.dev/blog/mai-image-2-6-in-app-editing/inbody1-20261014a.png)

*Official Flash playground surface for manual exploration; a production app still needs its own backend, access control, and request handling.*

This avoids treating every keystroke or “try one more” action as a final-image request. Keep the stages visible in the interface. A draft badge, a clear “make final” action, and a preview before the final call help the user understand both what is happening and which action may incur another provider request.

Avoid automatic promotion. A draft can look good but have a wrong detail; a final-tier result can still miss. Let the user compare, keep the prompt and selected reference with each result, and make regeneration an explicit action. If you later add an automatic quality check, show the rule and allow a person to override it.

## Put the model choice behind your own server

Do not expose a Gateway credential in browser code. Keep the key in a server-side secret store, authenticate the user against your app, validate the request, and have your server call the AI SDK. The announcement’s model IDs are `microsoft/mai-image-2.6` and `microsoft/mai-image-2.6-flash`. A minimal server function can make the choice explicit:

```ts
import { generateImage } from 'ai';

type ImageStage = 'draft' | 'final';

const modelForStage = {
  draft: 'microsoft/mai-image-2.6-flash',
  final: 'microsoft/mai-image-2.6',
} as const;

export async function createImage(input: {
  prompt: string;
  stage: ImageStage;
}) {
  const prompt = input.prompt.trim();
  if (prompt.length < 1 || prompt.length > 4000) {
    throw new Error('Prompt length is outside the supported range');
  }

  const result = await generateImage({
    model: modelForStage[input.stage],
    prompt,
  });

  return {
    image: result.image,
    stage: input.stage,
  };
}
```

This illustrates where your app makes the stage-to-model decision; adapt it to the provider configuration and return shape in your installed AI SDK version. Add authorization, request limits, storage, and error handling before exposing the route. The example deliberately omits reference-image handling, because accepted formats, size constraints, and the current number of references should be checked against the exact API path you deploy.

Keep the provider key server-side and scope its use to this feature. The Gateway announcement says a separate provider account is not required for this route, but you still need a Gateway key and usage billing. “One key” simplifies credentials; it does not make requests free or remove the need to set budgets and monitor usage.

## Measure the whole iteration loop

Model labels do not tell you the cost of your feature. Measure an end-to-end task with representative prompts, reference images, sizes, and edits. Record at least:

- requests per accepted final image, including abandoned drafts and retries;
- elapsed time from first prompt to accepted image;
- how often the user keeps a draft without a final pass;
- how often the final pass needs another edit;
- provider errors and timeouts by stage;
- spend per accepted result, using the actual billed configuration.

Run the same prompt set through both stages and keep a small human-reviewed sample. Score the properties that matter to your feature: subject consistency, edit fidelity, composition, text accuracy if relevant, and whether the user accepts the result. A faster model that triggers several extra edits may not reduce the full task cost. A higher-quality output that still needs a human correction is not a finished workflow either.

![Vercel's AI Gateway model list showing separate MAI Image 2.6 Flash and Image 2.6 rows with pricing and provider capability columns.](https://cdn.otf-kit.dev/blog/mai-image-2-6-in-app-editing/inbody2-20261014a.png)

*The model directory lists Flash and Image 2.6 separately; confirm current prices and limits when you configure the route.*

Set a per-user limit and an overall budget before inviting customers. Give every request an id so a retry from the browser does not accidentally create multiple generations. Decide whether users can cancel work, and handle a timeout without silently issuing a duplicate call. Persist the prompt, stage, model ID, request status, and a reference to the generated file according to your retention policy. Avoid logging raw uploaded images or private prompts unless your privacy policy and product design require it.

## Treat image editing as a stateful product feature

Editing is not just generation with a different button. The user needs to know which image is being edited, what should change, and what should remain intact. Store a stable version for each accepted image. Each new edit should point to its parent image and preserve the instruction used to create it, so a user can compare versions or go back instead of losing the original.

Make reference upload explicit. Validate file type and size on your server, define how long originals and outputs are retained, and explain whether the uploaded image is sent to an external model provider. If references are optional, make the no-reference path work too. Do not promise that every visual detail will remain unchanged; assess edit fidelity on your own examples and give users a way to reject or rerun an output.

The model playground is useful for a first manual check, but a production feature should be tested through the same server route and account controls that customers will use. Use a small fixture set with the kinds of product shots, layouts, or user-provided images your app handles. Recheck the provider documentation before launch when you depend on a limit or a specific format.

## Build the smallest useful version

Start with one clear use case, such as editing a product image or producing an illustration for a project card. Add the server route, the draft/final choice, a preview, one accepted-result action, and a request history. Then test the total loop with real users or representative internal prompts. If the two-stage path does not improve the balance of speed, output quality, and spend in your measurements, change the routing rather than defending the model split as a rule.

If you need a base for the surrounding SaaS screens, the [SaaS Dashboard kit](/templates/saas-dashboard) is an optional editable app/UI starting point with sign-in, projects, teams, sample analytics, tables, and a Vite/React/Hono/Postgres stack. It does not include MAI, AI Gateway, image generation, or this workflow. The kit is listed at $99 one-time; use it only if owning and adapting the app shell is useful for your project. The setup is separate from the provider integration and the model usage bill.

You can also read [how to measure AI Gateway fallbacks before rollout](/blog/vercel-ai-gateway-confidence-fallbacks) for a related example of testing a model-routing decision with your own workload. Apply the same discipline here: keep the route observable, record what users accept, and base the default on measured tasks rather than a provider description alone.

## Sources

- [MAI-Image-2.6 and MAI-Image-2.6-Flash now available on AI Gateway](https://vercel.com/changelog/mai-image-2-6-and-mai-image-2-6-flash-now-available-on-ai-gateway) — Vercel Changelog, 13 October 2026. The announcement covers the model IDs, AI SDK/CLI use, text generation and editing, and the intended Flash-versus-Image-2.6 workflow.
- [SaaS Dashboard kit](https://otf-kit.dev/templates/saas-dashboard) — current OTF product page checked 14 October 2026; describes the editable app/UI and its limits.
- [OTF pricing](https://otf-kit.dev/pricing) — current pricing page checked 14 October 2026.