MAI Image 2.6 pricing: estimates, references, and Flash

MAI Image 2.6 pricing is easier to understand if you start with the request: how much text it contains, whether it includes reference images, and how many pixels the model generates. A square-image estimate describes one case. It is not a fixed price for every aspect ratio or edit. On reAPI, credits are reserved before generation and reconciled after completion. ^[1]

There is also a model-selection question. MAI Image 2.6 Flash is a separate Microsoft model, positioned around faster generation and lower cost. That does not make it a setting inside a standard-model request. This guide separates the documented billing behavior from a practical method for choosing which model to evaluate. For current reAPI amounts, use the MAI Image 2.6 pricing table and playground. ^[2]

TL;DR

MAI Image 2.6 billing depends on text input, reference images, and generated pixels; a square-image quote is an estimate for that case.^[1]
reAPI reserves credits at submission and reconciles the charge after completion. The final amount can be lower or higher.^[1]
Reference edits use model-selected dimensions, so they need a different budget case from text-only requests.^[1]
Microsoft presents Flash as a separate, faster, lower-cost model. That positioning is not a reAPI benchmark or a Flash availability claim.^[2]
Read current estimates on the model page and exact completed-task amounts through ?include=billing, rather than copying a fixed rate into your application.^[1]

What changes MAI Image 2.6 pricing?

The documented billing dimensions are text input, image input, and image output. Generated image tokens follow the actual output area divided by 1,024. Reference inputs also contribute to the generation cost, so adding images is not the same budgeting case as sending the prompt alone. ^[1]

Request choice	What to consider before submitting
A longer prompt	More text can contribute to input usage
Reference images	Image inputs contribute to the charge
Larger output	More generated pixels contribute to output usage
Automatic framing	The final area is not fixed by the initial choice
Reference editing	The model selects the output dimensions
Another submission	A separate task can incur a separate charge

This table describes billing dimensions, not a set of surcharges. There is no universal price in this article for "one reference" or "one 2K image." Use the current estimate with your intended inputs, and retain the final charge from the completed task when measuring your own workload.

An estimate and a final charge answer different questions

Before generation, an application needs to know whether the account has enough credits to start. After generation, it can account for the actual completed work. reAPI therefore reserves the initial estimate and reconciles it when the task completes. A lower final amount releases the unused reservation; a higher amount can require an additional debit. ^[1]

Do not label the initial amount as a maximum unless your own application enforces a separate spending limit. The estimate is also not a promise that the final balance movement will equal an integer displayed on a compact button. Your accounting view should request ?include=billing and preserve the exact billing values rather than reconstructing a bill from the selected resolution label.

If actual cost is unavailable on a completed task, the implementation keeps the reservation and records a billing exception for reconciliation. That is a fallback path, not evidence that the estimate was exact. Failed generations follow the refund path. A successfully generated image that does not satisfy your creative brief is a different situation: it still completed the work. ^[1]

For an application, useful job records include the task ID, submitted settings, reference count, result dimensions, final usage, and whether the output was accepted. This is a suggested measurement plan. It helps distinguish an unexpectedly large canvas from a high number of creative retries without assuming either occurred in a particular test.

Why a 1K label is not one fixed pixel count

The output token calculation makes dimensions material. A 1024 × 1024 image contains 1,048,576 pixels, which corresponds to 1,024 output image tokens under the documented division by 1,024. A 1536 × 1536 canvas contains 2,359,296 pixels and corresponds to 2,304 output image tokens. These are dimension calculations, not quoted prices.^[1]

Frame shape matters because explicit dimensions must keep both sides at least 768 pixels while remaining within the total area limit. A 3072 × 768 image is a valid wide canvas at that limit. It has the same area as the 1536 × 1536 example, despite looking very different. A nominal tier should not replace that area calculation in a cost report.

Explicit pixel dimensions also follow a rounding rule: nonmultiples of 32 are rounded down. 1000 × 1000 maps to 992 × 992 under that rule. When you compare requests, record the actual output dimensions, not just the numbers typed into the form. The parameter reference explains the precedence of paired dimensions, pixel size, and ratio-based sizing.

The endpoint offers 1K and 2K resolution tiers. It does not offer 4K. A request containing a 4K string is not a way to buy a larger image through this model contract; it is an invalid request. ^[1]

Reference editing needs a separate budget case

MAI Image 2.6 accepts up to five reference image URLs on reAPI. References provide visual context, contribute input usage, and activate model-selected output sizing. The text-to-image size controls no longer determine the returned edit dimensions.^[1]

That makes a comparison such as "the same prompt at 2K, once with references and once without" less controlled than it first appears. The reference request changes the input and the sizing behavior together. Inspect the files and final charges before attributing the difference to one setting.

A useful evaluation can still be simple. Choose an existing product image, write one clearly defined change, and state what must remain. Record whether the output preserves the product shape and label well enough for the intended use. If it needs another generation or manual correction, include that work when judging the method. This is an editorial recommendation for your own evaluation, not a published MAI accuracy benchmark.

Reference count alone cannot establish whether an edit is economical. A second reference may provide an essential chair shape or product detail; an unrelated extra image may add confusion. Explain each reference's role and evaluate the resulting asset against the same acceptance criteria. The API guide includes an ordered-reference request and the polling flow.

MAI Image 2.6 and Flash are separate choices

Microsoft Learn lists MAI Image 2.6 and MAI Image 2.6 Flash as distinct preview models with generation and editing capabilities. It describes Flash as a faster, lower-cost variant, while the standard model emphasizes quality gains in areas including text, portraits, and commercial imagery. Those are Microsoft's product descriptions, not measurements from a reAPI comparison. ^[2]

Question	Standard model	Flash
Separate model?	Yes	Yes
Microsoft-documented task types	Generation and editing	Generation and editing
Stated emphasis	Quality and controllable editing	Lower cost and faster generation
Selected by `mai-image-2.6` here?	Yes	No

The reAPI page linked in this guide covers the standard model. It does not silently switch to Flash, and a Flash description on Microsoft's site does not establish that a particular reAPI Flash endpoint is available. Check the exact service's model list and parameter documentation before building an alternate-model request.

Microsoft's product page also presents the two variants separately. Its positioning is a useful starting point for deciding what to test, but your application may value different details. A poster with short lettering, a product image with a strict shape, and a disposable composition sketch do not have identical acceptance criteria. ^[3]

Compare the cost of accepted work

If both models are available in your chosen service, evaluate them with the same task definition and an explicit acceptance rule. For example, a product scene may need the correct silhouette, an unchanged label, and enough space for a headline. A mood-board image may only need the requested palette and composition. Write those requirements before looking at outputs.

Keep the comparison narrow. Use the same source images, record each submitted setting, and avoid changing the prompt halfway through one model's run while keeping the other unchanged. Record time to completion as well as time spent correcting or rejecting the result. Your application may care more about one of those delays, so keep them separate.

A practical metric is total generation spend divided by the number of accepted outputs. This is a suggested calculation, not a measured result for either model. It captures retries that a per-request quote leaves out. Keep manual correction time as a separate measure unless you have an agreed way to value it. Otherwise, a monetary total can hide an arbitrary assumption.

Do not turn a small internal test into a universal ranking. Report the prompts, source material, request settings, acceptance rules, and date with your result. That gives another developer enough context to judge whether the finding transfers to their work.

MAI Image 2.6 pricing FAQ

Is there one fixed price per image?

No. Prompt input, reference images, and generated pixels affect the bill. Use the model-page estimate for the request you intend to send, then retain the completed task's actual billing values.^[1]

Can the final charge exceed the estimate?

Yes. The initial reservation is an estimate, not a maximum. Completion can release unused reserved credits or require an additional debit. A separate application spending limit is a different control.^[1]

Does the number of references determine the whole price?

No. Reference inputs contribute to cost, but the prompt and generated output also matter. Reference editing additionally lets the model choose the final dimensions, so count alone is insufficient.^[1]

Does 2K mean I can request 2048 × 2048 pixels?

No. That explicit square exceeds this endpoint's 2,359,296-pixel area limit. The resolution tier does not replace the explicit-dimension constraints. Use a valid canvas and inspect the output dimensions.^[1]

Where can I read the precise final charge?

Request the task with ?include=billing and inspect the exact billing fields. The legacy usage.credits value is rounded to whole credits; it should not be used to reconstruct the precise amount.^[1]

Does the standard request automatically select Flash?

No. mai-image-2.6 selects the standard model here. Microsoft lists Flash separately; its availability and request contract must be checked for the service where you intend to use it.^[2]

Free access, polling, and repeat requests

Search results for free playgrounds do not establish free API usage on reAPI. MAI Image 2.6 is a paid, pay-as-you-go model here. Check the model page for the current quote before submitting. This guide makes no promise about another service's trial credits, eligibility, quotas, or continuing free access.^[1]

Polling an existing task does not create another generated image. Submitting the same prompt again creates another task and can create another charge. Keep the original task ID visible in your logs and user interface, especially when a browser reloads or a client stops waiting. Recovering the task's status is different from requesting a new image.

For a first MAI Image 2.6 budget, begin with the request your application actually needs, read its current estimate, and inspect the completed usage. Then measure accepted outputs across that workload. A published square-image example can help explain the billing model; your own inputs and acceptance criteria determine whether it is a useful budget for your product.

References

reAPI. MAI Image 2.6 sizing, billing, and task contract. Reviewed October 9, 2026: reapi.ai/docs/mai-image-2-6.
Microsoft Learn. Deploy and use MAI image models in Microsoft Foundry. Retrieved October 9, 2026 from learn.microsoft.com/azure/foundry/foundry-models/how-to/use-foundry-models-mai-image.
Microsoft AI. MAI-Image-2.6. Retrieved October 9, 2026 from microsoft.ai/models/mai-image-2-6.